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ABSTRACT 

The final report on the Council on Library Resources 
(CLR) Grant #**43 for the New England Library Information Network 
(NELINET) is divided into three parts. Section one is a general 
commentary on the NELINET project, which was conceived to test the 
viability of creating a centralized, regional capability to use 
electronic data processing techniques for technical processes and 
other service requirements of a network of libraries. The philosophy 
of the total project and of the system design planned to achieve 
project objectives is discussed. The NELINET system design and its 
transferability is reviewed in section two. Section three is a 
technical report on the hardware, software and system design of the 
project. (SJ) 
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Inasmuch as the work done under the terms of CLR-443 was 
part and parcel of earlier efforts made under a series of Council 
grants, it seems worthwhile to comment briefly on the philosophy 
of the total project and of the system design planned to achieve 
project objectives. 

The project, which has come to be known as "the NELINET 
project", was conceived to test the viability of creating a centrali- 
zed, regional capability to use electronic data processing techni- 
ques in support of the technical processing and other service 
requirements of a network of libraries. It was hoped that, if this 
capability could be demonstrated as being possible from an engi- 
neering view and economic from a management view, and if a working 
network of libraries could be created, the two things combined 
would serve to provide both a better way to perform traditional 
library tasks and as a vehicle for enabling libraries to render 
new kinds and dimensions of user services. 

The earlier grants had supported planning plus initial com- 
puter programming and library evaluation. As planning moved to the 
stage of research and development and as actual experimental pro- 
duction of technical processing services became a reality, several 
guiding principles evolved. As a group, they could be viewed as 
the framework within which discrete elements of project work have 
been carried out. 

One of the decisions made was that a grand system design in- 
volving years of planning should not be undertaken, and that systems 
work should be more practical than theoretical. An early state- 
ment specified that, "In order to minimize development costs, the 
approach to installation of regional processing should develop a 
task at a time. These tasks can be planned in such a way that the 
participating libraries will receive useful service while the long- 
range objectives. . .are being accomplished. '* Thus, it was decided 
to concentrate a great part of the project efforts toward the pro- 
duction of immediately useful technical processing services. The 
production of catalog materials— cards and labels— was agreed upon 
as the first task to be undertaken. At the same time, however, 
the project's larger objective in this was seen as being the 
creation of a regional data file useful for many additional services 
beyond the production of catalog materials. It was decided, further- 
more, to tie this catalog materials and data file creation work to 
the Library of Congress Machine Readable Catalog (MARC) . That 
data record’ was not seen as the sole source of information, but 
as the currently most usable record and as a superior model for 
long-range development. 
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Early on, of course, it was decided that all project develop 
ments would be undertaken with the objective of keeping costs at a 
minimum. Not only were management and financial resources very 
limited for the complicated and expensive project planned, but maxi 
mum effi iency was mandatory from the practical view of ultimately 
selling services to libraries at acceptable charges. 

Even though the need for a grand systems design was rejected 
there were certain guiding overall principles agreed upon for the 
projected automated system. One was that the detailed work done 
for any discrete task should be so designed as to possess a high 
degree of transferability — both from one working environment to 
another within the project, and frcm the New England regional net- 
work to other regional networks. Thus, all computer programming 
has been planned and executed in this framework. This involved, 
at the beginning of CLR-443, making a decision as to the specific 
computer capability desirable and to the pros-and-cons of the 
language to be used in program writing. So important was this 
decision that the Board felt an outside professional opinion was 
called for. It persuaded Mrs. Kenriette D. Avram of thf Libra:./ 
of Congress, and a person familiar with project development, to 
make the necessary assessment. Her evaluation constitutes Part II 
of this report. 

A further decision related both to costs and transferability 
was to seek a machine environment in which the manufacturer's own 
operating system provided much of the programming necessary, thus 
permitting project efforts to concentrate on applications program- 
ming, i.e. on library-oriented requirements. Additionally, it was 
decided to use as many manufacturer's utility programs as possible. 

Finally, the project's developers, as far as the actual 
services production system was concerned, saw it as essential that 
planned growth be a constant consideration. It was seen as manda- 
tory that possible equipment obsolescence be avoided and that 
machine configuration have maximum capacity and flexibility. As a 
corollary, it was agreed that the optimal system needed to achieve 
the goals involved would have to be a random access, time shared 
system using a disc type memory store rather than magnetic tape. 

Within this framework of broad decisions, the series of 
Council grants has resulted in an automated system for producing 
catalog materials for a network of libraries. The existing system 
is only a simulation of the one believed to be optimal, but the 
programming is wholly capable of transference to that optimal 
system if and when financial resources make that possible. And 
even the simulated production system can produce useful and 
marketable technical services to a network of libraries for a 
limited time. It can do this with a major reduction in service 
delivery time, in the MARC (II) format for catalog cards, and at 
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a cost which, while relatively high because of first-time experi- 
mental nature of the capability, is within reason* Much experience 
is needed to discover both limitations and additional uses of the 
system, but a sound base has been created from which to move for- 
ward to new specific tasks related to the whole. 

f 

The immediate objectives of work under this grant 
were to continue, complete, and augment the plan- 
ning and programming initiated under previous 
grants, and to test the effectiveness of this work 
by a series of pilot demonstrations of catalog 
materials production. 

As had been the case under previous CLR grants, the Board 
contracted with the firm Inf oronics , Inc. of Maynard, Massachusetts, 
for the necessary computer programming and systems development. 

The research and development staff of Inf oronics, Inc. also pro- 
vided the management needed to arrange and conduct the pilot demon- 
strations. The Board exercised an element of supervision over the 
broad technical developments and project management. Details of 
the technical work done by Inf oronics, Inc. and of the results of 
the pilot demonstrations are contained in Part III of this report. 

It is to be noted that completion of the CARD AND LABEL PRO- 
DUCTION, the CARD FORMATTER, and the SMERGE programs specified in 
the grant proposal was a continuation of the work started under the 
previous CLR grant— 425. Also, since the entire effort to produce 
catalog materials was based upon the Library of Congress' Machine 
Readable Catalog (MARC) record and format of cataloging data, a 
large portion of the work under this grant was involved with the re- 
writing of computer programs written earlier for the MARC I format 
so that use could be made of the new MARC II format. 

The computer program work done deviated from grant proposal 
specifications in three respects: (1) one program specified in the 

proposal was not written, (2) two programs not specified in the pro- 
posal were written, and (3) two programs specified in the proposal 
were not sufficiently debugged for deiinonstration use, while two 
others needed minor debugging at the time of grant termination. 

The LINE PRINTER program specified in the proposal was not 
written, since experience showed it to be unpecpajlgry in the light 
of the IBM utility software available and usable. 

The two programs, MAKTEN and PAPER, were not specified in 
the proposal, but were found essential in the light of the machine 
configuration being used and for the purpose of getting a cle^r 
identification of operating errors. Their respective functions 
are described in 'Pages 29-31 of Part III of this report. Both 
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programs were written for the PDP-10/50 computer and with orienta- 
tion for disc storage of data. 

Even though not specified in the grant proposal, the time 
and effort involved in writing these programs was clearly dictated 
by the requirements of (a) meshing the LC MARC II TO NELINET MARC II 
program, written for a PDP-9 computer, with the capacities of the 
larger PDP-10, and (b) of identifying clearly the keying and trans- 
mission errors found in the demonstration runs. These requirements 
might have been foreseen in the grant proposal, but the later deter- 
mination to write the new programs is considered a not unusual 
development in the sort of system work involved. In this connection, 
it should be noted that use of a PDP-9 computer was not provided for 
in the original plan of work. The use of this machine for handling 
the LC MARC II TO NELINET MARC II program was decided upon by 
Inforonics, Inc. as being useful and convenient, since it was 
located in house and also because it provided a capability to 
check the MARC II tapes as they were received. 

Two programs, POCKET LABEL FORMATTER, and SELIN LABEL FOR- 
MATTER, while coded, were not debugged sufficiently during the grant 
period to be capable of use during the pilot demonstration part. 

This deficiency was, of course, a major disappointment and can be 
ascribed indirectly to the failure in machinery and utility soft- 
ware experienced at the first service bureau facility used for data 
processing. This failure is discussed below. 

Two programs, CARD AND LABEL PRODUCTION and CARD FORMATTER, 
while adequately written for use during the pilot demonstrations, 
did require further debugging work at the time of grant termination. 
No change in program design would be involved in this work and the 
bugs were considered by Inforonics, Inc. as minor in character. 

The computer programming completed was, in the Board's view, 
of high quality. This was substantiated, in part, when it became 
necessary to abandon the first service bureau and move to a second. 
The programs were found substantially usable in the second machine 
environment, a fact which not only verified their basic validity, 
but also indicated that their transferability factor was high; the 
latter a consideration of major importance from the view of the 
entire project serving as a prototype for library network development. 



SYSTEM TESTING 
AND CATALO G 
fl&TEftlALS 
PRODUCTION 



The grant proposal called for a six-month testing, 
demonstration, and pilot operation period. The 
former phase was to include limited operation 
for testing and debugging during the course of 
ten production runs, while the latter was planned 



to involve twenty-six full-scale production runs. 
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As capabilities developed, neither of these objectives could 
be met. Both phases had to be se^srely restricted by constraints of 
time and money. Testing was reduced, therefore, to one full pro- 
duction run, plus a brief period of "rractice" runs using a low 
volume of requests for service, while full-scale production was 
limited to a five-week period during which only five regular pro- 
duction runs were completed. This latter phase was actually aug** 
mented somewhat by the processing within that time period of some 
500 special requests by the University of Connecticut. 

These major deviations from the proposed work plan were due 
to several unexpected developments. A major part of the problem is 
touched upon in Part III of this report on Pages 11-13, and was re- 
lated to hardware and software problems arising from machine and 
software deficiencies at the Applied Logic Service Bureau in 
Princeton. It is to be noted that some $7,000 of computer time 
registered at ALS was declined for payment from grant funds. 

Two further problems developed which had not been anticipated. 
The Inforonics staff encountered many more difficulties with the 
computer programming than they had counted on, and they found ad- 
ditionally that they had under-estimated the complexities of writing 
the programs for a time-sharing system. The net result of these 
findings was that much more time had to be devoted to the first 
experience with the PDP-10 and the Bryant 4000-2A disc and to the 
writing of computer programs than had been planned. Although the 
costs of machine usage were not affected, the use of the Inforonics 
staff had to be re-allocated as to function. While this resulted in 
only a modest increase in personnel costs in dollars, it meant a 
major loss of staff time available for testing and production. 

The Board recognizes that this kind of prollem is not uncom- 
mon in experimental development work of the kind here involved. A 
machine breakdown cannot be anticipated, nor can all of the complexi- 
ties involved in breaking new ground in an automated communications 
system. Nevertheless, this particular aspect of CLR-443 pointed to 
a serious communications deficiency between Inforonics, Inc. and the 
Board. While the Board is satisfied that good engineering judgment 
was used— there was, in fact, no alternative to the course taken, it 
would have been more satisfactory to all concerned had the extent 
and implications of these problems been known by the Board, the 
Council and the participating libraries, as they were occurring. 

A review and tabulation of the demonstration results is 
given on Pages 62-105 in Part III of this report. 

Several operational conclusions can be drawn from the demon- 
stration experience: 

1. The LC MARC II tapes provide a usable record from 

which serviceable customized catalog cards can be produced 




in a network context, i.e. functioning as a central 
machine file of data electronically accessible to a 
number of libraries located at remote distances; 

2. the turn-around times between request for 
cards and their delivery is appreciably less than 
usually experienced in commerce between libraries 
and the Library of Congress? 

3. the maximum effectiveness in the production 
of catalog cards using MARC II data lies in the 
favorable meshing of the extent and speed with 
which the Library of Congress generates such 
records and the point in the cataloging process 

at which the library requests cards? 

4. the cost of producing catalog cards from 
the MARC II tapes by the system so far developed, 
while somewhat higher than projected in the final 
report on CLR-425, is still within the purchase 
range of the participating libraries? 

5. the use of a magnetic tape data storage 
base will very rapidly become inefficient for 
catalog card production processing as that file 
grows in size; 

6. several months of further experience with 
a fully producing system are necessary to provide 
both users and operators with maximum competence 
to make optimal use of the system. 

Even though abbreviated, the demonstration phase has provided 
in the Board's opinion, information which supports the NELINET con- 
cept for catalog materials production based on the MARC II records, 
and has indicated the probability of a viable cost for producing 
this service in the NELINET context. 

The Board and the participating libraries believe that an 
effective operational simulation of an eventual regional technical 
processing center has be^n developed as the result of Council -sup- * 
port through the series of grants culminating in CLR-443. In 
spite of the set-backs and deficiencies experienced during this 
latter grant period, the Board and the libraries are satisfied 
that solid progress was made. A first system now exists which, 
when refined through additional technical development and ..opera- 
tional experience, can serve to provide other and extensive 
services to libraries. 
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NETWORK Obviously, one of the essential ingredients to a 

DEVELOPMENT successful project is a network of cooperating 

and coordinated libraries. While the grant pro- 
posal carried no specific stipulations concerning 
work in thi 3 area, the support of a capacity at the Board to moni- 
tor the project may be seen as implying such a responsibility. 



The group of the six New England state university libraries 
which made up the project's network when work began remain the core 
group today. During the course of CLR-443, an additional university 
library, the Boston campus at the University of Massachusetts, com- 
mitted itself to participation and has been invited to join the 
network . 



f' 



» 




X 

\ 



| 

s 

■ 



o 

ERIC 



Support from the core network members has always been good. 
Many meetings and many hours of effort have been expended by the 
chief librarians and their staffs on behalf of the project over 
the past three and one-half years. During the course of CLR-443 
and the previous grant, CLR-425, the tempo and extent of library 
participation in the project was accelerated and expanded. During 
the latter grant period, for example, library staff members were 
given instruction and practice in system operation, while five of 
the libraries committed themselves to the purchase of technical 
processing services as these became available from the system. 

During CLR-443, while experience with system operation was 
minimal, there was a good measure of additional staff involvement 
and a major increase in participation by the chief librarians. At 
a series of meetings called by the Board, these men were briefed 
in project development and asked to render judgments as to 
priority tasks for research and development. This latter effort 
was taken very seriously, since it was recognized as an essential 
element in writing a detailed Master Plan for the project; this 
plan is now ready for final preparation. 

From those meetings has come agreement, furthermore, to 
undertake the appointment at each library of a staff member who, 
after adequate indoctrination, could serve as the focal point for 
project technical liaison. It is not envisaged that this would be 
a full-time responsibility at this juncture, but does serve as evi- 
dence of the sustained interest in the project's concept and 
potential value on the part of network members. The Board has 
asked, furthermore, that the participating libraries create a 
regional committee of staff representatives who can give regular 
advice to the Board and project developers. The libraries have 
agreed to do this. One reason for such a request is the Board's 
belief that very close association with project work will be 
increasingly necessary from this point forward. 

It is worth noting, in this general context of network 
development, that the project's Advisory Committee now includes 
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one of the leading State Librarians from the region, as well as the 
director of an organized library network from outside New England. 
Both appointments serve as evidence of the Board's interest in 
broadening the network's scope. Additionally, it is pertinent to 
record the increased tempo of interest by other libraries in the 
region in learning of the project. As of this writing, the Board 
has been requested to present four major briefings to major 
libraries and groups of libraries in the region. Some of this un- 
doubtedly arises from the increased publicity about project develop- 
ment provided by the publication of the newsletter, NELINET NEWS, 

by the Board. 

The Board has not actively solicited new network members. 

Such action is considered premature at this juncture. Nevertheless, 
it is abundantly evident that an expanded network will be essential 
if the economics of the project are to be favorable. The Board has 
considerable evidence that response to the project's services will 
be favorable once a viable system is in operation. The prognosis 
for success in this is positive enough to warrant a belief that a 
large and supportive network can be forged in the interest of the 
project. It is equally clear that a major augmentation of the 
Board's capacities to provide supervisory and administrative sup- 
port for such a network is essential. 
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Henriette D. Avram 

The New England Library Information Network (NELINET) 

Project is concerned with the creation of a machine-readable 
file of bibliographic data and a computer-oriented technical 
processing center to provide service to the libraries of New 
England. The economic and functional viability of the pro- 
jected NELINET Center rests on the assumption that it will 

operate in a ^'ully dedicated, time-shared, random access 

/ 

oriented cpfnputer environment. The work in progress in the area 
of catalog card and label production, involving basic research 
and development, will test the technical feasibility of that 
assumption, and will be considered as operating in a simulated 
NELINET Center environment. The main difference between the 
simulated and projected environments is that the former, although 
it will utilize a magnetic disc in selected computer processing 
operations, e.g., the formatting of catalog card images, will 
rely primarily on magnetic tape for the storage and searching 
of bibliographic records; in the projected environment, a random 
access device will be utilized throughout as the storage medium. 

Since mid- 1966, the New England Board of Higher Education, 
the interstate agency sponsoring the NELINET Project, has entered 
into a series of contractual agreements with the firm of In- 
foronics, Inc., of Maynard, Massachusetts, whereby the latter would 
provide the necessary systems design and software to implement 
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the projected NELINET Center. Because the funding for the de- 
velopmental work culminating in the creation of this Center will 
be secured primarily from granting agencies and/or from the net- 
work libraries , it is most important to the New England Board of 
Higher Education that two basic requirements be met: 

1. The application program modules designed for the 
simulated environment should work with a minimum 
of modification for the projected environment. 

2. The final product, i.e. , the hardware, systems 
design, the procedures and the software that 
comprise the NELINET Center, should be useful to 
the entire American library community. 

I was asked by the New England Board of Higher Education 
in January, 1969 to evaluate the work completed by Inforonics 
to that date to determine if the two requirements stated above 
were being fulfilled. An analysis of this type involves the 
concept of transferability. In the first instance, the trans- 
ferability is internal to the developmental stages of the NELINET 
Project itself; in the second case, it relates to the extent to 
which all or some of the NELINET system can be used by the con- 
stituent libraries of the network, or by other library networks, 
for all or some of the same purposes as it was designed for the 
New England Board of Higher Education. 

The planning for both phases of the NELINET Project in- 
cludes on-line access. In the simulated environment, the libraries 




that are part of the network will transmit their requests via 
a teletype for bibliographic data and/or file updating to Infor- 

s' 

onics, Inc. , and the latter will re-transmit these requests on- 
line via Dataphone to a service bureau containing the hardware/ 
software configuration specified for the system. As more ex- 
perience is gained in the Project, i.e., as technical and cost 
factors are evaluated more carefully, the libraries themselves 
may eventually be hooked directly on-line to the service bureau. 

When the NELINET Center is established, the network li- 
braries will be connected directly to the Center in an on-line 
time-shared basis. Because the primary function of the NELINET 
bibliographic data bank will be to serve as a machine- form catalog 
that can be searched on-line by the network libraries in support 
of cataloging and acquisitions, this time-sharing aspect be- 
comes critical. In the simulated environment, a service bureau 
will have to be used; this will not be the case for the final 
projected Center. Accordingly, Inforonics, Inc. has specified 
that a particular computer, the Digital Equipment Corporation 
PDP-10 , be used in both phases of the NELINET Project. Although 
this decision was based on a number of factors, four of the pi- 
votal ones were that: (1) the PDP-10 v?as capable of time-sharing 

in the sense that multiple unrelated program jobs could be run 
relatively concurrently, utilizing a time-slicing algorithm to 
allot portions of operating time to each job; (2) the manufacturer 
had written the software to provide this kind of time-sharing? 

(3) the equipment was available in a service bureau operation 
using this software at the onset of the project, i.e. , 



in the 



simulated environment? and (4) the configuration, i.e., hardware 
and software was capable of expansion to the estimated number 
of users in the projected environment. 

The simulated NELINET environment has itself been divided 
into two distinct phases. The first of these was a pilot operation, 
based entirely on magnetic tape storage of Library of Congress 
MARC I records, in which a Digital Equipment Corporation PDP-1 
was utilized for the computer processing required to produce 
catalog cards and labels, and in which the computer programs were 
coded in PDP-1 machine language? the second phase is the one that 
has been described above, that is, a pilot operation based on 
Library of Congress liARC II records, in which a PDP-10 will be 
utilized for the computer processing required to produce catalog 
cards and labels, and in which the computer programs will be coded 
in PDP-10 machine language. It was originally intended to experi- 
ment with MARC II records on the PDP-1, utilizing the programs 
written for MARC I records modified to incorporate the fundamental 
differences between the two types of records. The reasons why 
this original intention was abandoned are fully recounted in the 
final report on CLR-425, and will not be repeated here. 

The decision having been made, has the first requirement of 
the New England Board of Higher Education been satisfied with 
respect to the eventual transition of application program modules 
from the simulated environment to the projected environment using 
the PDP-10? The design specifications of the program modules that 
are to be used in both phases, e.g., catalog card production, book 
pocket label production, book spine label production, etc., were 
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analyzed and considered to be designed to work equally well for 
the tape system and for the random access system. The programs 
used to search magnetic tapes by Library of Congress card number 
in the simulated environment will not, and, in fact, should not, 
be used in the random access system of the projected environment, 
where searching will be by author/title as well as by LC card 
number. File organization in a magnetic tape system is inherently 
serial, and the techniques for a random access system should be 
entirely different and far more sophisticated. If the random 
access device were used to perform as a tape, i.e. , in a sequen- 
tial mode, without the utilization of random access capabilities 
and directory techniques, the system would be inefficient and 
badly designed. Therefore, it can be stated that all effort is 
being expended by Inforonics, Inc. to design modular programs to 
transfer as many as possible from the simulated to the projected 
environment. 

The second requirement of the New England Board of Higher 
Education was to insure that the final product would be useful 
to the library community. 

Insofar as systems of the kind represented by NELINET are 
concerned, trans ferability may have a variety of meanings, i.e., 
it may refer to the ability to transfer the entire system, both 
hardware and software; the ability to transfer the system speci- 
fications; the ability to transfer the logical flow diagrams of 
the software configuration; the ability to transfer the software 
itself; or the ability to transfer the knowledge gained from the 
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operational experience. Two factors that will significantly affect 
the character of the transferability that is possible for the 
NELINET system center around the computer selected and the pro- 
gramming language used. 

The hardware, i.e., the PDP-10 was chosen because it was 
available in a service bureau operation and had the capabilities 
required for the projected environment. The question most fre- 
quently asked will be "Would not a more popular piece of equip- 
ment have been the better choice because of the likelihood that 
more libraries will have access to the equipment?" The majority 
of the computer market is held by a manufacturer whose equipment 
at that time did not have the existing capability of being run 
in a time-shared mode (as defined earlier in this report) and 
could not be readily £ound in a service bureau. The manufacturer 
initially intended to provide a time-shared system but this was 
withdrawn some time prior to the Inforonics decision. Therefore, 
the equipment of the major manufacturer was not in reality a 
choice that met the immediate needs of the NELINET Project. 

Even if the major manufacturer's equipment had satisfied 
the NELINET needs, there is perhaps something to be said in 

favor of designing a library system for a different hardware 

\ 

configuration. In the case of the NELINET Project, the exper- 
ience that will be gained on a computer configuration with certain 
characteristics will provide a partial answer to the question 
often asked, "What is an ideal hardware configuration for NELINET- 
type networks?" The knowledge gained from this experience and 
made available to the library community exemplifies one of the 



ings of transferability, i.e., the transfer of knowledge. 

The main significance of the choice of equipment for the 
NELINET Project lies less in the particular manufacturer whose 
equipment is used than in the fact that the entire NELINET 
system, i.e., the procedures and the software, can only be trans- 
ferred to a library network with the same equipment configuration. 
Since the New England Board of Higher Education is committed to 
making all of its findings available to the library community, 
including the procedures and software of the NELINET Project, 
such availability would represent complete transferability to 
any library network possessing the same hardware configuration, 
or willing to acquire it. 

It should also be noted that the system specifications, 
i.e., the logic and the flow, are independent of hardware and 
can be transferred independently of hardware specifications. 

System design is time consuming and costly in terms of the man- 
power required, and such information would be extremely useful 
for other systems planning a NELINET-type operation. Similarly, 
the program specifications and logical flow diagrams, although 
not completely independent of hardware, include design aspects, 
e.g. , search strategy, etc., that would be useful for other net- 
work designers. Again, this activity is expensive in terms cf 
manpower, and any assistance that could be secured would sub- 
stantially reduce costs for others. In both cases (system and/or 
programming specifications) the New England Board of Higher Educa- 
tion will make this information available to the library community. 
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The decision of Inforonics, Inc. to program in PDP-10 
machine language rather than in a higher level language, however, 
is more complicated vis-a-vis the assessment of its consequences 
on the transferability of NELINET experience, since software can 
not be transferred from one manufacturer’s computer configuration 
to another 1 if it is not written in a higher level language, and 

r 

even this does not guarantee transferability. 

Timing is of prime importance in time-shared systems, even 
for those programs operating in a background mode. Although pro- 
grams can be written faster in terms of elapsed programming time in 
such higher level languages as COBOL and FORTRAN, a good programmer 
will write more efficient code in machine language. The NELINET 
system, to be a useful system in terms of service and cost for 
the New England libraries, should be written as efficiently as 
possible; this effort is not a "one-shot" job, but a system that 
will be operating for a long time. 

Thus, the decision to program in PDP-10 language for the 
applications that will be processed in a time— shared environment 
seems warranted in terms of the functional technical requirements 
of the NELINET Center. Even if it had been decided to program in 
a higher level language (both COBOL and FORTRAN are implemented on 
the PDP-10), the complete transferability without modification of 
the resulting software is open to some question. 

Granted that modification of software is simpler, (again 

^■Some manufacturers claim compatability in the use of machine lan- 
guage code or supply translators for one machine language to the 
other. To the best of my knowledge, neither been claimed by a 
manufacturer for PDP-10 machine code. 
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open to some question and dependent on what was written, who wrote 
it originally and who is modifying it) than a complete rewrite, 
there is still another factor to be considered. If the appli- 
cation programs were written in COBOL, the potential user of the 
programs for another system would have to base his system on 
NELINET design, that is, use the NELINET type peripheral equip- 
ment, formats, etc. On the other hand, if the NELINET programs 
were designed for the lowest common denominator (design for the ^ 
least sophisticated configuration to which the programs might 
be transferred), in an attempt to insure transferability, then 
NELINET would be adversely affected. 

This is not a utopian world. The computer community and 
the library community are making progress towards standardization. 
Both have a long way to go. In the interim there are problems in 
transferring computer systems from one computer to another (even 
when the same manufacturer's equipment is being upgraded) within 
an organization; these are complicated many times over when the 
concern is across organizations. The use of higher level lan- 
guages must be evaluated in the context of each system being 
designed and the capabilities and requirements of potential users 
of the entire system or components of the system. Blanket state- 
ments concerning the transferability of programs written in higher 
level languages are fraught with danger. 
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1. INTRODUCTION AND SUMMARY 



1.1 HISTORY 

NELINET, since its inception in 1966, has been 
sponsored by the New England Board of Higher Education. 

The work done under the present grant is a continuation 
of work done under four previous grants from the Council 
on Library Resources, which can be summarized as follows: 

1. CLR-354 : Initial Systems Study, determined 

the initial specifications for a computer- 
based New England library technical process- 
ing center and its services; 

2. CLR-374 : Catalog Data File Creation, resulted 

in the development of the initial computer 
programs based upon the Library of Congress 
MARC I Format; 

3. CLR-385: Systems Design and MARC I Pilot 

Operation, resulted in the initial studies 

of library acquisitions processes and random- 
access file organization and searching, as 
well as in the demonstration of catalog card 
and Selin label production services, using 
the computer programs developed under CLR-374; 
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4. CLR-425 : MARC I Pilot Operation and Conversion 

to a MARC II System, an extension of the work 
of CLR-385, provided for the continuation of 
the MARC I -based pilot operation through the 
end of July, 1968, and for the beginning of 
the systems design and programming required 
for catalog data file creation and for catalog 
card and label production based upon the new 
Library of Congress MARC II Format. 

1.2 WORK PERFORMED 

Under the present grant, which began on February 
15, 1969 and ended on November 15, 1969, the systems design 
and program specifications begun under CLR-425 were completed, 
and a set of programs were written to generate catalog cards 
and labels from Library of Congress MARC II tapes. 

A demonstration of services was conducted with 
the five participating libraries over a five week period, 
beginning October 8, 1969. The libraries transmitted requests 
once a week, the MARC records were searched, and catalog card 
sets were produced for the items found. The label formatting 
programs were not sufficiently debugged to provide labels 
during this demonstration. 
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1 . 3 ACCOMPLI SHMENTS 

With the completion of the work done under this 
contract, NEL2NET now has a system for g©n©rati»e eatainsrin* 
products on which its future services can be based. There 
are two significant features of this system. First, its 
design has been based on the MARC II format with the 

t 

definition and identification of the bibliographic data 
elements kept completely intact. Second, the system has 
been designed for a large scale computer, Digital Equipment 
Corporation’s PDP-10, so that it has a large capacity for 
growth . 

This report describes this system, the programs 
involved, and the demonstration that took place. In addition, 
complete program documentation has been submitted to the 
New England Board of Higher Education. 

Assuming that the Library of Congress continues 
to distribute MARC tapes, and that the remaining bugs are 
removed from the programs, the system can be used to produce 
catalog cards ready for filing and labels ready to be applied 
to books within a very short turn-around- time. Increasing 
the volume of output from the system by increasing the 
number of requests submitted can be accomplished with 
comparative ease. 
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Using the results of the present experiment, these 
services are estimated to cost $1.56 per title processed, 
with a projection that these costs will be lower in the 
future . 



These accomplishments lead naturally to a number 
of short range and long range objectives. The system 
may be used to begin the creation of a machine readable 
file of the holdings in the participating libraries. Today 
great emphasis is placed on libraries sharing resources and 
the government has directed monies toward this end. But 
effective and efficient sharing of holdings depends on 
(1) quickly locating the material, and (2) getting the 
material from where it is located to where it is needed. 
Machine readable files of holdings provide the means of 
quickly locating materials, either by printed lists or 
machine form catalogs. With the additional capability for 
creating machine readable records for items not on the 
MARC II file, this service can be greatly expanded. In 
this way, sharing processing facilities increases the 
ability of the participating libraries to share resources. 
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2 . SYSTEM DESCRIPTION 

The NELINET MARC II system in current pilot opera- 
tion has been designed to be the logical precursor to a 
fully dedicated technical processing center that will serve 
the New England library community. Such a center would 
require data processing equipment costing many hundreds of 
thousands of dollars. The present system has been designed 
to provide an operational simulation of the dedicated center 
without requiring the capital commitment. The objectives 
and methods of the system, and the machines, communications, 
programs, and operating procedures that comprise the operating 
network are discussed below. 

2.1 OBJECTIVES 

The goal of operational simulation without capital 
expense has required that the system be developed and 
operated in a service bureau environment. Within this 
context, we have had the dual objectives of creating a 
body of programs and procedures that would be easily trans- 
ferable from the service bureau to a dedicated center, and, 
simultaneously, providing useful services and products to 
the participating libraries. For reasons discussed at 
length in earlier reports, initial system services were 
chosen to be technical processing services in support of 
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cataloging, using the Library of Congress MARC II magnetic 
tapes as the primary data base. A main objective of the 
present contract has been to complete the conversion of the 
earlier MARC I NELINET system (CLR-425) to the MARC II 
format and to move from a batch processing system on Inforonics' 
computers to an on-line processing system on a service bureau 
machine identical to that planned for the fully-dedicated 
technical processing center. 

These objectives have been met in good measure and 
during the course of this contract we have additionally shown 

evidence of the transferability of the programs, 

point was dCT.onotr.ted »l.»o we wwe torced to switch service 

bureaus when the one we used Initially had an extended period 

of disc and software problems. 

2.2 THE MARC II DATA BASE 

In simplest terms, the system as designed accumulates 
MARC II records as they are received from the Library of 
Congress, searches this data base when requests for cataloging 
services are received, and processes those records which are 
located so as to produce catalog cards, Selin labels, and 
book pocket labels . 

The MARC II data base is central to the system, is 
very large, and is growing rapidly. As of November 5, 1969, 
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we had accumulated approximately 28,000 records, averaging 
500 characters each. This base is growing at the rate of 
about 1,000 records per week. 

2.2.1 Data Base Storage 

The particular economics of the service bui’eau 
environment have required that our MARC II data base be 
kept on magnetic tape rather than disc, despite the fact 
that the fully-dedicated syoteu planned would «ho m 

other random-access mass storage. 

A large disc file, such as would be used in the 
eventual fully—dodios/teu system, would cost in the neighbor- 
hood of $250,000 and have a capacity of 500,000,000 characters, 
or about 1,000,000 MARC II records, less directories or other 
information. This cost is in the order of 50*? per 1,000 charac 
ters, or about 6.25$ per 1,000 characters per year, assuming 
an eight-year service life. 

Using an identical disc file at a service bureau, the 
s ame 1,000 character storage would cost about $4.50 per year, 
on a one-year storage contract. (One "Mass Storage Unit” 

(MSU) , of 1,024 characters, typically leases for 37.5$ per 
month on a one year contract.) Short-term lease is even 
more expensive, typically twice the long-term rate - 75$ 
per month, or 2.5$ per day per 1,024 characters. In addition 
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the filn loading charges make short-term use of such a large 
storage file at a service bureau even more costly. 

From the time-shared service bureau point of view, 
random-access storage is a fixed resource that represents 
one of the limits on the number of time-shared users that 
can be accommodated. Hence, it is not unreasonable that 
its policies and pricing discourage the use of extremely 
large data bases. One bureau limits the maximum storage 
contract to 10,000 MSU, Considering that it may service 100 
users and 10,000 MSU is about 1/8 of the total disc, this is 
not an overcautious limit, but at the same time, it is 
barely sufficient to hold three months’ collection of MARC II 
records, without directories. Furthermore, the service 
bureau charge for a tape unit is $2.50 minimum per half hour 
or less. This is a modest charge, though data transfers are 
expensive. Current charging schedules are 1£ per 1,024 words 
of core per second. The second is broken up into 60 "ticks” 
but even short transfers are charged a minimum of 3 "ticks” 

(or 50,000 microseconds; a long time by processing standards). 
These figures are cited to show that allocation of costs in a 
»t#rvino bureau euvii'oumeut is quite different from that which 
would hold true in a fully-dedicated center. 

Hence, for the demonstration of the present project, 
magnetic tape storage has been used for the data base. 
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Because tape searching time increases extremely rapidly as 
the data base grows larger, tape usage is only feasible as an 
interim solution, since it offers economies only under the 
simultaneous conditions of a moderate size data base and a 
scheduled batch processing system. 

2.3 COMPUTERS USED 

A Digital Equipment Corporation (DEC) PDP 10/50 has 
been used as the basic systems computer. In a fully-dcdwtod 
system, this machine would be capable of performing all 
technical processing now contemplated. During the present 
demonstration however, this machine, located at a service 
bureau, was used for only a part of the technical processing. 
A Digital Equipment Corporation’s computer PDP-9 was used at 
Inforonics for the initial conversion of the 1C MARC II tapes 
to tapes in NELINET MARC II, an internal format that, while 
fully convertible back to LC MARC II, is more convenient for 
internal processing. Use of an in-house computer permits 
verification of the MARC tape before sending it to the 
service bureau. 

An IBM 360/40 computer is used at another service 
bureau (Information Services, Inc., Wellesley, Massachusetts) 
because it drives an IBM 1403 line printer with the required 
upper and lower case print train. The choice here was dic- 
tated by both the particular hardware and the quality of the 
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service bureau. The usual service bureau line printer, if 
used for nothing more than information-only page printout, 
frequently suffers from poor alignment and other ills that 
would disqualify it for the creation of crisply printed 
catalog cards. This particular installation specializes 
in the creation of computer produced charity solicitation 
letters with a "hand-typed” personalized apne-»-awoe. Their 
printer consequently is extremely well— maintai nod. 

2.3.1 Disc Files 

Though the current system holds the data base on 
no + 4 o w*>o , i pruewsing programs have been written to 
make use of disc files, where appropriate. Many PDP-10 
service bureaus have one or more large discs. The large 
Bryant disc (4000-2A) was initially a widely popular choice. 
Some service bureaus are now planning, however, to use 
Memorex discs; and some are installing IBM 2314 discs. So 
far, our programming has been disc independent, since most 
service bureaus have been using the standard DEC Monitor 
(operating system), in which disc storage is treated as an 
extension of core, from the applications program point of 
view. Storage is parcelled out in fixed length segments by 
the monitor so that the monitor, not the applications program, 
has control over the precise physical disc location that 
holds a particular piece of information. By this means, 
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the applications programs have been kept independent of 
particular disc geometries. For large scale retrieval oper- 
ations on disc files it is frequently desirable to utilize 
data location on the basis of the specific disc. Some 
service bureaus are planning to provide the facility to 
bypass the monitor in such cases, as well as to provide 
small user-dedicated disc packs. These options have not 
been required on the present project. 

2. 3. 1.1 Disc Problems 

During the course of the project, it was necessary 
to switch service bureaus because of disc and software 
problems at the first service bureau. Had we waited for 
the problems to be solved, we would have suffered much more 
than the two month delay this breakdown did occasion. 

The service bureau had two complete systems with 
a third one going into service (systems A, B, and C) . The 
purpose of having multiple systems is to provide "graceful 
degradation" in case one system has problems. Thus, switching 
one system out of service for maintenance or testing would 
not terminate service, but would merely increase the waiting 
time for service on the systems that are operating. However, 
the Dataphone lines from the Boston area were multiplexed in 
Boston into a private line that connected only to the "A" 
system. Hence, when trouble developed with the disc on this 
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system, there was no way to switch systems. 

Another problem was traced to a dirty disc. It 
should be noted in passing that it takes only a microscopic 
amount of foreign matter on the disc surface, or airborne, 
to make it "dirty". With critical head-to-surface spacings 
in the 100 micro inch range, maintained by a boundary layer 
of air moving with the disc surface at speeds in excess of 
120 miles per hour, it does not take very much dirt to cause 
severe problems. Air contamination is the classic enemy of 
disc files, dince contamination is a self accellerating 
process wherein dust can cause scraping of the oxide on the 
disc surface, causing errors and more contamination, until 
finally head meets disc, and the disc is said to have 
"crashed". The results are always fatal when this occurs, 
in that at least one track becomes permanently damaged. 
Hence, air filtration is normally maintained at very high 
levels, typically 95 % efficiency for one micron dust parti- 
cles. 



The problems were, in part, hardware deficiencies 
due to a faulty disc. During the period when "slow degrada 
tion" of the equipment was taking place, Inforonics was 
always the first user to be affected, since the size of our 
data base was considerably larger than that of the other 
users, and error rates that would not usually affect the 
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accurate read-in of a short problem would invariably prevent 
the accurate read-in of a 10,000,000 character-plus data 
base. 



This experience would seem to show that large data 
bases cannot be served on equipment that is even faintly 
marginal, and that duplication of equipment does not auto- 
matically guarantee "graceful degradation" during periods of 
trouble. While these problems constituted an extremely un- 
fortunate occurrence for both the project and the service 
bureau, it did force us to prove what we had maintained: 
that the body of programs were completely transferable to 
other service bureaus and other PDP-10's. 

2 . 4 TELECOMMUNICATIONS 

The participating libraries are currently equipped 
with Teletype machines with dual connection to WX lines 
and Dataphone lines. The TWX lines have been used for 
inter-library loan communications and the Dataphone lines 
have been used for transmitting requests to the processing 
center and for transmitting requests and program data from 
the processing center (Inforonics, Inc., Maynard, Massachu- 
setts) to the PDP-10 at the service bureau (The Interactive 
Sciences Corporation, Braintree, Massachusetts) currently 
being used for this purpose. The Teletype keyboards in use 
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are the single-case 33ASR models. It was planned early in 
the project to switch to the more flexible 37ASR models 
(double-case) when these became generally available. Although 
announced in 1966, these are just beginning to see limited 
service and have not been available for this project. While 
Dataphone lines are required to communicate with the computer, 
and would be required at the libraries to service double-case 
Teletype keyboards or more advanced display terminals, the 
low speed transmission of request tapes via the Model 33 
Teletype could be handled by either TWX or Dataphone. 

The six state university libraries in New England 
are between 50 and 200 miles distant from the processing 
center in Maynard, and between 40 and 265 miles distant from 
each other. The transmission cost of a 30-minute Dataphone 
message to the center averages about $5.28; the transmission 
cost of a 30 minute inter-library TWX message averages about 
$7.50. The transmission cost of a 30 minute Dataphone 
message from the center to the Service Bureau averages about 
$3.00. In the case of Dataphone, the 30 minute period cor- 
responds to roughly 150 cataloging requests, for an approxi- 
mate average total transmission cost of 5.5$ per request. 

2.5 PROCEDURES AND PROGRAMS 

There are about fifteen principal machine operations 
involved in running the overall system. They are summarized 
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her© and shown on the accompanying charts. Detailed descrip 
tions of the programs involved are contained in the next 
section. 

1. Weekly Conversion of LC MARC II Data : 

Each week a tape is received from the Library 
of Congress containing bibliographic records 
in MARC II communications format. These are 
converted by the LC MARC II TO NELINET MARC II 
CONVERTER program to the NELINET internal 
format prior to further processing. 

2 . Request Validation : 

Teletype requests from the libraries are re- 
ceived as paper tape, then retransmitted to 
the service bureau where they are operated on 
by the program PAPER, which loads them onto 
the disc. They are then run through the pro- 
gram REQUEST VALIDATOR, which checks for er- 
rors normalizes permissible variations in 
request format. Two files result: an error 

file, and a validated request filef' ^ i 

3 . Request Sort Key Generation : 



The validated requests are then run through 
the program SORT KEY GENERATOR, which creates 
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a sort key derived from the Library of Congress 
card number and the request identification num- 
ber, and creates a file of requests vith sort 
keys as headers. 

4. NELINET MARC II Data Input : 

The week's bibliographic records which have 
been converted to the NELINET internal format 
are then transferred from tape to disc on 
the PDP-10 by the program MAKTEN. 

5. NELINET MARC II Data Sort Key Generation : 

The program SORT KEY GENERATOR then opera tea 
on the data output from MAKTEN to create a 
file headed by sort keys. 

6 . Sorting of Reque sts a n d NELINET MARC II Data : 

The program SORT accepts the new bibliographic 
records and the validated requests, and 
creates one ordered file containing both. 

7. Searching and Merging : 

The SEARCH/MERGE program (SMERGE) then accepts 
the cumulative NELINET master file containing 
all the bibliographic records which have been 
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received from the Library of Congress and 
processed into the system, as well as the 
previously unmatched requests, and the file 
of new bibliographic records and new requests , 
and performs functions of searching and merging 
to create four new files: a new cumulative 

NELINET master file of bibliographic records 
and unfulfilled requests; a file of found 
bibliographic records with their associated 
requests; a file of the requests that were 
matched, which serves as holdings information; 
and a file of not-found messages. The new and 
old NELINET master files are on magnetic tape . 
At the end of the run, statistica l and 
performance data of the run are printed out. ^ 

8. Sorting of Found Records : 

The file of found bibliographic records and 
their associated requests is now sorted by 
the request number in the request sort key. 

This contains the identification of the 
requesting library and the library’s sequence 
number for the request, and results in the 
products being returned to the libraries in 
their input order. 
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9. Card and Label Processing : 

The program CARD AND LABEL PRODUCTION (CLPP) 
then operates on the sorted found records and 
creates four output files. These correspond to 
the output products van ted, and contain local 
information , as required, derived from the 
requesting libraries' stored "profiles”. The 
separate files are cards, Selin labels, book 
pocket labels, and error messages. One record 
is created in the output files for each separ- 
ate output item (e.g., one record *or each 
entry in a card set, one Selin label for each 
physical volume) • > 

10. Card Formatting ; 

The program CARD FORMATTER operates on the 
file created by CLPP and causes card images to 
be formatted and output on a magnetic tape in 



11. Selin Label Formatting : 

The SELIN LABEL FORMATTER program operates ou 
the Selin label output created by CLPP and 
punches a paper tape to drive the label-typing 
typewriter. 



line printer format, 
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12. Pocket Label Formatting : 

The POCKET LABEL FORMATTER creates a magnetic 
tape ccutalnlng formatted book lAbel Images 
in line printer format. 

13. Card Printing : 

The output tape from the CARD FORMATTER is then 
printed on continuous form card stock on a 
1403 line printer, using an IBM utility program. 
These are then put through a card cutter. 

14. Pocket Label Printing : 

# 

The output tape of the POCKET LABEL FORMATTER 
is printed on the same line printer; this time 
with continuous fora label stock. 

15. Selin Label Typing : 

The paper tape output of the SELIN LABEL 
FORMATTER is then used to drive a Dura Typewriter 
with a Selin label attachment. 
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3. SYSTEM PROGRAMS 

A total of twelve programs is involved in gener- 
ating catalog cards and labels from the MARC II tapes dis- 
tributed by the Library of Congress. Eleven of these were 
developed for this project. They are: 

1. LC IIARC II TO NELINET MARC II CONVERTER 

2. MARTEN 

3. PAPER 

4. REQUEST VALIDATOR 

5. SORT KEY GENERATOR 

6. SORT 

7. SEARCH/MERGE (SMERGE) 

8. CARD AND LABEL PRODUCTION (CLPP) 

9. CARD FORMATTER 

10. POCKET LABEL FORMATTER 

11. SELIN LABEL FORMATTER 

The twelfth program is an IBM utility program, 
Information Services Print Variable length Program, which 
drives a line printer. While there was some doubt during 
the design phase of the project that this program could be 
used to print catalog cards, when tested with output from 
the CARD FORMATTER, it was found that it could. 

Most of the programs represent different functions, 
but the three formatting programs are exceptions to this. 
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They all perform the same function, but do so on diff iren * 
types of records. 

Some of these programs operate or the bibliographic 
data from the Library of Congress; eo«e operate on the 
request data submitted by the pA 4 *»lcipAting libraries; and 
others operate on t>«tu typo a of data, bibliographic and 

request . 

All the program* used in the system, except the 
LC MARC II TO NELIKET MARC II CONVERTER And the IBM utility 
program that prints the cards, have been programmed for 
Digital Equipment Corporation's PDP-10 computer. The former 
program was programmed for a Digital Equipment Corporation - 
PDP-9 computer. The IBM utility program that prints the 
cards is a 360 program that drives a 1403 line printer. By 
using the "Batch” feature in Digital Equipment Corporation’s 
PDP-10 monitor system, the individual PDP— 10 programs may 
be set up so that they run as if they were one. 

The NBLINET MARC II system, although it presently 
generates only catalog cards from MARC tapes, was designed 
with a broad range of possible uses and additions to the 

j system in mind, e.g., data creation for books not included 

! marc II* • coverage, book catalog production, etc. Since 

\ 

the eventual configuration is seen as random-access storage, 

l 

f 

t 

f. 
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the programs developed are disc-oriented, although the 
master file is on magnetic tape. 

A complete package of program documentation for 
all programs developed has been deposited with the New 
England Board of Higher Education. Only a brief description 
is presented here. 

3.1 LC MARC II TO NBLINET MARC II CONVERTER 

This program accepts tapes distributed by the 
Library of Congress in the MARC II communications format 
and outputs tapes that are in the NELINET Internal format. 
The NELINET Internal format uses a ’’mapped" record structure 
wherein the tags, plus the address (pointer) of the data 
field relative to the starting position of the first data 
field, are placed in a map (or directory) at the front of 
the record. The data fields follow thi« map. The map 
can contain a maximum of 100 entries (one entry per tag) 
and data fields are limited to 3,000 characters per physical 

record. 

The Library of Congress MARC II communications 
format also uses a "mapped” record structure. The control 
information that accompanies each tag entry in their map, 
however, consists of the length of the data field that the 
tag identifies as well as the address of that data field 
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relative to the starting position of the first data field. 

In the NELINBT internal format, the map does not contain 
the length of the data field? the length can be generated 
when desired. 

In the Library of Congress communications format, 
the tag identifying each field is in the nap (directory) . 

The indicators which further identify each field occupy 
the first two positions in the data field. The 1/5 MARC II 
TO NELINBT MARC II CONVERTER program converts, by algorithm, 
the Library of Congress tag and indicators into au 18 bit. 
tag which identifies the data ftoide co~ P i*t*lv. These 18 bits 
appear as the tag representation in the map in the NEl.iwkt 
internal format. Having the indicator expressed along with the 
tag in the map eliminates looking at the data fields to 
determine if certain processing functions are to be performed. 
For example, certain operations are performed when the main 
entry is tbo subject of the book. This information is shown 
by an indicator that is in the data field in the Lila ary 
Congress record. By having this information in the map, 
processing is simplified. 

This program also convert, the ASCII character codes 
into the NELINBT internal character codes and aoves the data 
contained in the leader, which cannot be regenerated auto- 
matically, into the variable fixed field. 
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The program output is 7-level, odd parity, 200 bpi. 
The 200 bpi can be easily changed to 556. 

Original plans called for modifying the NELINET 
MARC I system to accept MARC II data, convert it to its 
MARC I equivalent, and then process the data with the MARC I 
programs. Por the reasons given in the final report on CIA- 
425, plans were changed and it was decided to design a new 
MARC 1 1 -based system for the PDP-10, the computer that had 
been selected for the NELINET processing center. 

This program had already been written before this 
decision was made, and was programmed for the PDP-9 computer 
at Inforonics. It was found very convenient , during this 
project, to have this conversion take place at Inforonics. 
When trouble does arise in running this program, the Library 
of Congress tapes can be checked out and bad tapes can be 
vapor ted more quickly than if the conversion took place at 
the service bureau. 

At completion, the program types out the number of 
input and output records, and the number of parity errors 
and illegal characters. It also identifies the record 
number and data field tag that contained the erroneous or 
Illegal data. 
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3.2 MAKTEN 

This program performs two functions. It trans- 
fers data from magnetic tape to disc and it converts the 
addresses (pointers) in the data fields from word pointers 
to character pointers . 

As explained in the preceding section, the LC 
MARC II TO NELINET MARC II CONVERTER was written for the 
PDP-9, a small 18-bit word computer. Its output format 
is word oriented. MAKTEN accepts this output, and converts 
the word pointers to character pointers since character 
pointers are more efficient when using the PDP-10 36-bit 
word computer. It then writes the records on a disc. 

The output records are in the standard NELINET 
internal ’'mapped” format with the 18-bit tag occupying the 
first half of a PDP-10 36-bit word and the address of the 
starting character position of data occupying 
the other half of the word. A separate directory file is 
also output which contains the starting word address and 
word count for each record. All the disc files are struc- 
tured in this manner for random-access. 

Messages are typed on the t«i«* ***>«• *-* **r»'*/ 

output errors occur. At termination, the program types 
out the number of records processed. 
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3.3 PAPER 

PAPER is a utility program that accepts the requests 
transmitted via the Teletype at Inforonics and loads them 
onto a disc. It assumes the input to be in 7-bit ASCII 
code, as output by the teletypewriters. The terminating 
sequence to end each request must be: backslash, backslash, 

carriage return. The ASCII 7-bit character codes are con- 
verted to their 6-bit NELINET internal character code equiva- 
lents. The output recor * is still in the NELINET input 
format, i.e., a carriage return that is not followed by a 
tab indicates a tag, a tab separates the tag from the 
data, a carriage return followed by a tab indicates data 
continued on a new line. 

Since tho tab key on the 33ASR model Teletype does 
not physically move the carriage, the "f* character is 
Koy*»d in^toad of the tab so that it can be proofread. PAPER 
converts the 'V* to a tab. 

PAPER con ■#-<*■! n sr t.wn editing ion tines to allow dele- 
tion of errors discovered while keying. They are (1) delete 
a line; and (2) delete a record, signaled by a "\KL" (kill 
a line) and a "\KR M (kill a record), respectively. (See 1 
Instructions For Teletypists in Appendix C for further detail. 

Whereas the NELINET internal format allows a maximum 
of 3,000 characters in the data fields in a MARC bibliographic 
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record, only 996 characters are allowed for a request record 

in the internal format because the amount of data in a re- 
quest is small. At completion, the program types out the 
number of records processed. 

PAPER may eventually become part of the REQUEST 
VALIDATOR. During the demonstration it was kept separate 
so that keying and transmission errors could be more easily 
identified. 

3.4 REQUEST VALIDATOR 

The REQUEST VALIDATOR accepts the output of the 
program PAPER, validates each record, and outputs two disc 
files. One contains all the correct records, the other 
contains the error messages. Both files are in the NELINET 
internal format, i.e., they are mapped records as described 
in Section 3.1. Again, the data fields are allowed a maxi- 
mum of 996 characters per physical record as in the PAPER 
program . 

Each record is checked to assure that all tags 
input are valid, that the tags that are required are not 
missing, and that the tags that should appear only once are 
not duplicated, . as follows: 
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Unique 



req (Request No.) 


yes 


yes 


crd (LC Card No.) 


yes 


yes 


loc (Location, Copy, 
Volume Data) 


no 


no 


call (Local Call No.) 




yes 


supp (Supplement No.) 


no 


yes 



Each field is then verified as follows: 



req — Must contain 2 alpha characters (library code) , 

2 digits (year), a hyphen, and a 1-6 digit sequence 
number. This may be foll/wod by an "m". 

crd — May have a 1-3 character alpha prefix. Must have 

2 digits, a hyphen, a a 1-6 digit sequence number. 
This may be followed by a suffix. 

loc — Block 1 (locatio* symbols): 

Alphas, spaces, periods, and baokolashes are valid. 

— Block 2 (copy number): 

Numerics, spaces, dollar signs, hyphens, periods, 
commas, and "c"s are valid. 

— Block 3 (volume numbers) : 

Alpha# , numerics, spaces, dollar signs, hyphens, 
comnas, and periods are valid. 
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loc — Blocks 4, 5, and 6 (Suppress Catalog Cards, Suppress 
Selin Labels, and Suppress Book Pocket Labels): 

The letter "x" is valid. If an upper case shift 
is input, it is eliminated. 

— Block 7 (extra main entries) : 

The numbers 1-7 are valid. 

call — Alphas, numerics, spaces, slashes, hyphens, commas 
and periods are valid. 

supp — One numeric or one alpha is valid. 

This program also normalizes the following sequences 
of spacing characters: 

1. Drops spaces before carriage returns. 

2. Drops sequential carriage returns. 

3. Drops sequential tabs. 

4. Drops spaces before tabs. 

5. Converts carriage return tab to a space. 

The error messages output on the second file con- 
tain the date, the program name, the record identification, 
the error description^ and the data which caused the error. 

The identification for each record contains the library code 
and the request number, so that the errors can be sorted 
back by library. These messages and the number of good and/or 
rejected records are typed out for each library at completion. 
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The experience in using this program and the PAPER 
program during the demonstration is described in Section 
4.2.1. 

3.5 SORT KEY GENERATOR 

The SORT KEY GENERATOR converts variable field 
data to fixed field data suitable for sorting. It gen- 
erates sort keys for the bibliographic records which contain 
the Library of Congress card number, and for request records 
which contain both the Library of Congress card number and 
the library’s request number. 

The input files to the program are in WELlNJiT i 
format, and in NELIWET internal character codes. The charac- 
ters in the items selected for conversion to sort keys are 
normally converted to 6-bit ASCII character sets for ease of 
sorting on the PDP-10. However, the program contains six 
different conversion tables, any of which can be selected for 
any item. Escape coding is also provided for the general 
case; that is, all special character sequences and case data 
can be stripped. The output files generated from the program 
contain the sort key followed by the input record in the 
NELINET internal format. The SORT KEY GENERATOR is a com- 
pletely table dependent program whose functions are derived 
from these tables. The number of records processed is typed 
out at completion. 
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The Sort Key is six PDP- 10 words long and contains 
thirty-six six-bit characters. The contents of the Sort 
Key are shown in Figure 3-1. 

3.6 SORT 



The SORT program for the NELINET system employs a 
standard Shell Sort. The SORT sequence is specified by tables 
and can sort any number of keys in any order. The starting 
bit and the number of bits in the string are specified for 
each key. Normally the character codes in the keys are 
six-bit ASCII codes. 

Core allocation for SORT is dynamic, i.e., the 
program requests core from the monitor as it needs it. This 
feature allows one to specify the maximum number of records 
and, therefore, the maximum amount of core which can be 
used. Time sharing service bureaus use a time/core algorithm 
in pricing jobs. The ability to change the amount of core 
allows one to achieve the best price per job with different 
service bureaus . 

The program first passes the input file (any 
number is possible) , pulling the keys and record addresses 
for the input records until it has exhausted the setup value 
for the number of records. It then sorts these and writes 
them out on a temporary file. When all the records have been 
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processed, it merges the temporary files into one, and then 
creates a new directory file to the original input file. The 
output file becomes a copy of the input file but with a 
different directory. 

The SORT program is used to sort request records 
and the week's bibliographic records by Library of Congress 
card number before searching and then again after searching 
to sort the matched request and bibliographic records by 
library request number. 

3 . 7 SEARCH/MERGE (SMERGE) 

Input to SMERGE consists of: 

1. A magnetic tape, containing in one numeric 
sequence by Library of Congress card mirabor* 

(a) the bibliographic records which have been 
received from the Library of Congress and 
processed into the NELINET system and, (b) the 
unfulfilled requests which were unmatched in 
previous runs. This is the old cumulative 
NELINET master file. 

2. A disc file in one numeric sequence by Library 

of Congress card number , containing: (a) new 

requests from the libraries and, (b) new bib- 
liographic records from the Library of Congress. 
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In the demonstration of this project, the 
system was run once a week and one tape was 
issued each week by the Library of Congress . 

If the system were run more frequently than 
once a week, input to this program would not 
always contain new bibliographic records. All 
input records are in the NELINET internal 
format and all contain a sort key. 

SMERGE searches for bibliographic records which 
match the requests submitted by the libraries and creates 
a new cumulative master file. The program matches requests 
and updates the file in one pass to save the high costs of 
processing large files. 

8MJSRG& outputs three disc 'files and one magnetic 
tape file: 

(1) A disc file of records containing bibliographic 
data and request data that will be used as 
input to the card production program. Each 
record in this file contains the request reooi*d 
and the bibliographic record that matched it, 
as well as the request sort key so that it 
can be sorted back by library. 
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(2) A disc file of requests that were matched. This 
file contains each fulfilled request as it was 
input by the library. Although it is not pre- 
served, at present, in the future it could 
serve as a file of holdings data. 

(3) A disc file containing not found messages for 
the requests that were not matched. Each mes- 
sage contains the library* s request number 

and the Library of Congress card number in sort 
key form so that they can be sorted by library 
if desired. The number of times that the request 
has been searched is also contained in the 
message . 

(4) A new cumulative NELINET master file. This 

file is on magnetic tape and contains (a) all 
the bibliographic records that wu ti»» «ta 

i (u) an -the unfulfilled requests 
that were on the old master file that were not 
matched in the new weekly batch of bibliographic 
records, (o) the new weekly batch of biblio- 
graphic records, and (d) all the new requests 
that were not matched by either the biblio- 
graphic records in the old master file or the 
bibliographic records in the new weekly tape. 
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This tape becomes the input tape for the next 
run. Presently, its density is 800 bpi. 

SMERGE is actually a three way equal to or less 
than match/merge program which works on two input buffers 
and one output buffer. It was designed for use with large 
random- access files but presently uses two magnetic tapes, 
one in and one out, plus an input disc file. 

The program works entirely from the data in the 
sort keys and does not look Internally into the map or the 
data fields in the record. Since the bibliographic records 
do not contain a request number in their sort keys, they can 
be distinguished from request records. They will also sort 
ahead of a request for the same Library of Congress card 
number . 



A comparison is first made on the input buffers. 

The lower card number is moved to the output buffer. The 
card number in the output buffer is then compared to the card 
number in each input buffer. If it is unequal to both, it 
is output on magnetic tape and the lower of the two input 
buffers is moved to the output blAV# VTwV'OO Xb 

repeated. If the card number in the output buffer equals 
the card number in either (or both) the input buffers, a 
chock is made that the input buffer represents a request. 
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The appropriate data is then output to the holdings and card 
production in*, t files, the input buffer that contained the 
matching request is refilled, and the cycle repeats. 

SMERGE also keeps a count of the number of passes 
on each unfulfilled request which did not match. When re- 
tention periods for keeping unfulfilled requests on the file 
have been determined, SMERGE can purge (or otherwise handle) 
unfulfilled requests which have* been on the file this long. 

The not found messages for all unfulfilled requests 
written on the disc are, at present, typed out at the end 
of the run on the Teletype , and have been used in checking 
out the system. They could, if desired, be sorted back into 
library request number order and transmitted back to the 
libraries. This was not done, however, because the investi- 
gators did not feel that they knew the most efficient way of 
handling these messages in a full scale operational system* 
Should the libraries be notified of all their unfulfilled 
requests on the file, or only those submitted in th* latest 
run? Should the requests be transmitted back to the libraries 
or printed and mailed? Finally, would not fovnd messages be 
of any use to a library in a full scale operational system 
After retention periods for keeping requests on the file have 
been determined? 
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At termination, the program types out the total 
number of bibliographic records on the new master file, the 
number of unmatched requests remaining on the file for each 
library, the number of new requests that were matched for 
each library, and the number of old unfulfilled requests that 
were matched in this run for each library. 

3.8 CARD AND LABEL PRODUCTION PROGRAM (CLPP) 

CLPP accepts the output of SMERGE and generates for 
each input record, four types of records: 

1. A record for each entry required for a set of 
cards . 

2. A Selin record for each physical volume owned. 

3. A pocket label record for each physical volume 
owned . 

4. Error message records. 

Each type of record is output onto a separate disc 

file. 



The profile for each library contains information 
about the library’s processing specifications, including: 

1. Oversize determinations. 

2 . Oversize symbols . 

3. An indicator for Selin label production. 
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4 . An indicator for pocket label production. 

5. Conventional title treatment. 

6. Main entry as subject treatment indicator. 

7. Library symbol to appear on catalog cards. 

8. A table of valid branch, department, and 
special shelf locations giving the card 
requirements . 

In processing each record, the program will examine 
the library’s profile and perform the operations specified. 
The profile information for each of the five participating 
NELINET libraries is summarized in Table 3-1. 

CLPP performs a number of processing fur*** 0118 on 
the bibliographic and request data, incJ«dir\s the following: 

1. Generation of overp^ nt headings from tracings, 
titles, and ser 1 -* 68 statements. 



1 The variations in practice found among the participating 
libraries are described in ’’Library Networks: Cataloging 
and Bibliographic Aspects”, by Ann T. Curran, to be published 
by the University of Illinois in the ’’Proceedings of the 
Seventh Annual Clinic on Library Applications of Data 
Processing”* 
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Conn. 


Mass. 


N.H. | 


R.I . 


Vt. 


1. 


Oversize determination 

(a) 

(b) 

(c) 


)28 


29-40 

41-60 

)60 


28-37 

37 


'SI 

* 


28-30 
31-61 
>61 . 


2. 


Oversize symbol 

(a) 

(b) 

(c) 


f 


+ 

folio 
F Folio 


ovsize 


f 


Q 

F 

FF 


3. 


Make Selin labels 


yes 


no 


yes 


yes 


yes 


4. 


Make Pocket labels 


yes 


yes 


yes 


no 


yes 


5 . 


Conventional titles 
are to appear on cards: 














(a) always 

(b) never 

(c) only if they 
appear on LC 
printed cards 


X 


X 


X 


X 


X 


6. 


Subject added entries 
are to be made when 
the main entry is the 
subject. 


no 


yes 


no 


yes 


yes 


7. 


Output printed symbol 


ctu 


MU 


NhU 


RU 


vtu 
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8a. Card 


requirements — Connecticut 














Special 


Main 


Subject 


Added 


Shelf 


Location 


Branch 


Shelf 


Entries 


Entries 


Entries 


List 


(Main) 






2 




1 


1 


1 


Acq. 




X 


2 




1 


1 


1 


Bibl. 


• 


X 


2 




1 


1 


1 


Catl. 




X 


2 




1 


1 


1 


f 




X 


2 




1 


1 


1 


G.P.D. 




X 


2 




1 


1 


1 


Music 


X 




3 




2 


2 


2 


Pharm . 


X 




3 




2 


2 


2 


Ref. 




X 


2 




1 


1 


1 


Spec. 


X 




3 




2 


2 


2 


8b. Card requirements — Massachusetts 












Special 


Main 


Subject 


Added 


Shelf" 


Location 


Branch 


Shelf 


Entries 


Entries 


Entries 


List 


(Main) 






2 




1 


1 


2 


AG EN 


X 




3 




2 


2 


3. 


BURGO 


X 




3 




2 


2 


3 


BUS 


X 




3 




2 


2 


3 


CHEM 


X 




3 




2 


2 


3 


CRAN 


X 




3 




2 


2 


3 


EDUC 


X 




3 




2 


2 


3 


ENGIN 


X 




3 




2 


2 


3 


ENT 


X 




3 




2 


2 


3 


+ 




X 


2 




1 


1 


2 


FOLIO 




X 


2 




1 


1 


2 


FFOLIO 




X 


2 




1 


1 


2 


FOOD 


X 




3 




2 


2 


3 


FOR 


X 




3 




2 


2 


3 


HOME 


X 




3 




2 


2 


3 


LABOR 


X 




3 




2 


2 


3 


LAND 


X 




3 




2 


2 


3 


MATH' 


X 




3 




2 


2 


3 


MORR 


X 




3 




2 


2 


3 


MUSIC 


X 




3 




2 


2 


3 


NUR 


X 




2 




1 


1 


2 


PER 




X 


2 




1 


1 


2 


PHYS 


X 




3 




2 


2 


3 


PLANT 


X 




3 




2 


2 


3 


PSYCH 


X 


— 


2 


- - 


1 


1 


2 
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# VOX U . 




Special 


Main 


Subject 


Added 


Shelf 


Location 


Branch 


Shelf 


Entries 


Entries 


Entries 


List 


REF 




X 


2 


1 


1 


2 


RES C 


X 




2 


1 


1 


2 


SHADE 


X 




3 


2 


2 


3 


SPEC 


X 




3 


2 


2 


3 


TECH P 


X 




2 


1 


1 


2 


VET 


X 




3 


2 


2 


3 


WALT 






3 


2 


2 


3 


fin _ f!n.rd reauirements -- New Hampshire 










Special 


Main 


Subject 


Added 


'Shelf 


Location 


Branch 


Shelf 


Entries 


Entries 


Entries 


List 



(Main) 

Archiv 

Biochm 

BioSci 

Browse 

Call 

Chem 

Eng 

Folio 

German 

Hj 

j 

LS 

LSJ 

LSRef 

Math 

Mcard 

Mfiche 

Mfilm 

Mprint 

MS 

NH 

Nt 

Ovsize 

Pam 

Per 

Phys 

Ref 

RefBib 

Spec 

Vault 

y 



4 

X 4 

X 5 

X 5 

X 4 

X 4 

X 5 

X 5 

X 4 

X 4 

X 4 

X 5 

X 4 

X 4 

X 4 

X 5 

X 4 

X 4 

X 4 

X 4 

X 4 

X 4 

X 4 

X 4 

X 4 

X 4 

X 5 

X 4 

X 4 

X 4 

X 4 

X 4 



1 

1 

3 

2 

1 

1 

2 

2 

1 

X 

1 

2 

1 

1 

1 

2 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

2 

1 

1 

1 

1 

1 



/ 



1 

1 

3 

2 

?L 

1 

2 

2 

1 

1 

1 

2 

1 

1 

1 

2 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

2 

1 

1 

1 

1 

1 



1 

1 

3 

2 

1 

1 

2 

2 

1 

1 

1 

2 

1 

1 

1 

2 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

2 

1 

1 

1 

1 

1 
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8d. Card requirements — Rhode Island 


Location 


Branch 


Special 

Shelf 


Main 

Entries 


Subject 

Entries 


Added 

Entries 


Shelf 

List 


(Main) 






1 


1 


1 


1 


Archiv 




X 


1 


1 


1 


1 


Blatz 




X 


1 


1 


1 


1 


Ext 


X 




2 


2 


2 


2 


f 




X 


1 


1 


1 


1 


J.F.K. 




X 


1 


1 


1 


1 


mcard 




X 


1 


1 


1 


1 


mfiche 




X 


1 


1 


1 , 


1 


mfilm 




X 


1 


1 


; 1 


1 


NML 


X 




2 


2 


2 


2 


R.I.C1 




X 


1 


1 


1 


1 


Rare 




X 


1 


1 


1 


1 


Ref 




X 


1 


1 


1 


1 



8g. Card r equirements — V ermont 



Location 


Branch 


Special 

Shelf 


Main 

Entries 


Subject 

Entries 


Added 

Entries 


Shelf 

List 


(Main) 






3 


1 


1 


1 


F 




X 


3 


1 


1 


1 


FF 




X 


3 


1 


1 


1 


J 




X 


2 


1 


1 


1 


Mfilm 




X 


3 


1 


1 


1 


MP 




X 


3 


1 


1 


1 


Per 




X 


3 


1 


1 


1 


Q 




X 


3 


1 


1 


1 


R 




X 


3 


1 


1 


1 


R Ind 




X 


3 


1 


1 


1 


S 


X 




4 


2 


2 


2 


TR 


X 




4 


2 


2 


2 


W 


X 




4 


2 


2 


2 
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2. Generation of tracings for title and series 
entries when the overprint headings are taken 
from the title and series statements. 

3. Generation of the appropriate number of main 
entries, added entries, subject entries, and 
shelf list cards from the profile and tracings 
data. 

4. Generation of the appropriate Arabic or Roman 
numeral to be printed before each tracing. 

5. Break-up of the Library of Congress call 
number string into segments which can be printed 
in the margin of the cards and on the labels. 

6. Generation of a record for each label from 

the summarized statement of copies and volumes. 

7. Addition of the library* s location symbols 
(including oversize when appropriate) to the 
call number. 

CLPP is a general purpose, table driven, pre- 
processing program which yields disc files for input to the 
formatting programs. 

Parameters in CLPP are set up by two types of 
tables: the specific library profile table (LPT) and the 
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general entry table GENT. LPT is searched by the library 
identification code. This table contains all the data 
which is unique to a specific library, such as oversize 
determination. It also contains a slot for the library's 
statistics, such as the number of entries generated. GENT 
contains the parameters which are common to all libraries, 
such as what data fields are output and in what order, 
leading and trailing messages for data fields, special 
character conversion needed for a field, etc. 

The program can modify itself using data found in 
the tables. For instance, GENT is set up to output all con- 
ventional titles, but LPT allows libraries to choose whether 
they want all conventional titles, none, or only those printed 
on Library of Congress cards. 

The program was designed to output a separate record 
for each entry rather than have the next program, the CARD 
FORMATTER, generate the subject and added entry records from 
the main entry and the overprint headings. If» ih the future, 
it is desired to perform a machine sort of tb© i'ec©x*ds by 
entry to simplify filing cards into the catalog, the sort 
would be made on the output of CLPP. 

The program types the number of input records pro- 
cessed for each library and the number of all output records 
generated for each library at completion. 



50 . 



3 . 9 CARD FORMATTER 

The CARD FORMATTER accepts as input the disc file 
of catalog records that has been output by CLPP, and formats 
the data contained in each record into a card image (or 
images if the record extends to more than one card) that can 
be printed on an IBM 360 computer using an IBM utility print 
program. Each card image is output as a separate record onto 

the magnetic tape. 

The major functions of the CARD FORMATTER include: 

1. Horizontal and vertical positioning of each 
data field. 

2. Breaking lines on spaces and hyphens. 

3. Right- justifying data fields when necessary. 

4. Converting NELINET internal character codoc 
into the character codes required by the 
output device. 

5. Eliminating delimiter character sequences or 
converting them to spaces, carriage returns, 
or hyphens as appropriate for the data field. 

6. Generating continuation card Headers and "con- 
tinued on next card" messages when necessary. 
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7. Truncating overprint headings when they con- 
tain more than three lines of data. 

The CARD FORMATTER is a table driven program con- 
sisting of three parts - the formatter, the input-output 
routines, and the processing routines for each type of data 
field. Briefly, the input routine reads a disc input record, 
the formatter arranges this data into card images by using 
the data field processing routines, and delivers the data to 
the output routine, which, in turn, packs it into a suitable 
form for line printing and then writes the data out onto mag- 
netic tape. This continues until all input records have 
been processed. 

The formatter portion of the CARD FORMATTER is the 
heart of the program. It requests an input record from the 
disc and re- formats the data. The input record is a mapped 
record with the entries in the map in a fixed sequence. 

The formatter scans the map and processes each data field 
via the data field processing routines, placing the data in 
the desired output buffer. Currently two output buffers are 
used, each holding 17 lines of data, 46 characters per line - 
the size of a catalog card. The data that is common to all 
continuation cards is placed in the first buffer. Other data 
(normal bibliographic data) is placed in the second buffer. 



o 

ERIC 



80 



52 . 




The data in the first buffer is then "overlaid" onto each 
continuation card image . 

The data field processing routines - one for each 
different type of data — are special macro commands which 
define the manner in which the data is to be processed. 

They set and alter various parameters and switches and in- 
sert spaces, carriage returns and ’’messages” into the out- 
put page. 

The formatting routine converts all input data 
from NELINET internal character codes to 8-bit EBCDIC codes. 
The IBM print train with the TN character set is presently 
being used to print the catalog cards. This character eot 
does not contain some of the characters in the MARC II data 
base. At the moment, these characters are just eliminated 
from the printed cards but special conversions have been 
planned to try to make up some of the special characters by 
combining certain characters in the TN set. (See Table 3-2.) 

Output from the formatting portion of the program is 
sent to the output routine in two instances: when a card 

is full, i.e., 17 lines have been filled; or when the last 
data field in the input record has been processed. The 
output routine uses pointers to access the card images. It 
picks up the card information and compresses it into the 
format necessary for compatibility with seven channel IBM 
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TABLE 3-2 

MARC II CHARACTER CONVERSIONS FOR TN CHARACTER SET 
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MARC II CHARACTER CONVERSIONS FOR TN CHARACTER SET 
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Standard Variable Block and Record Format. The output 
routines have been kept separate to facilitate changing to 
other output devices if desired. 



On termination, the program types out the number of 
input records and the number of cards generated. 

The format of the cards generated (see Figure 4-5) 
intentionally resembles the format of typed cards intended 
for reproduction via the unit card method. In a computer 
based system, each card need not be an exact replica of the 
main entry with a fixed amount of space reserved at the top 
of each card for overprint headings. In the NELINET system, 
the familiar, but less efficient from a space standpoint, 
format was copied because it was felt that it would be more 
acceptable to librarians. More efficient formats may evolve 
when librnrians begin to think in terms of machine based 
systems with new techniques for updating, coordinating, and 
displaying data. 

One problem that is encountered in automatic format- 
ting of data when the top margin is a fixed number of lines 
should be noted. The CARD FORMATTER is designed to truncate 
overprint heading? at three lines. (The main entry begins 
on line four on all cards.) Long title overprint headings 
for title added entry cards can be truncated at three lines 
and pose no problem of being considered acceptable. Long 
corporate author added entry headings and long series 



58 . 



headings do present problems. In a series heading that is 
longer than three lines, the last part which includes the 
number, is chopped off, making filing, etc. more difficult. 

One possible solution would be to print the entire 
overprint heading with tne main entry starting on the next 
line. This method could be used for all entries and would 
save space when the entries are short. This would, in 
some cases, result in continuation cards for one entry and 
not for the rest of the card set, and would therefore, be 
different from the familiar unit record concept. 

To provide for more than three lines of overprint 
heading by always starting the main entry on line five or 
six would not be desirable because most added entries are 
less than three lines long. Perhaps the best compromise 
would be to refrain from starting the title part of an 
author-title added entry on a new line (the usual format 
for author title overprint headings) if the heading were 
long and then type, manually, any that were still unaccept- 
ably chopped. This would happen perhaps a couple of times 
per thousand cards of output. 

3.10 POCKET LABEL FORMATTER 

The input for this program is the disc file of 
pocket label records output by CLPP. Each record is in the 
NELINET internal format and contains a call number, location 
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symbols if present, a copy number if more than one is owned, 
a volume number if it is a multivolume work, and abbreviated 
author and title data. 

This program is similar to the CARD FORMATTER in 
design but has fewer data fields to process. Characters, 
both data and delimiter, are processed by a similar technique. 
Output again is on magnetic tape in EBCDIC character codes 
to be run with the same IBM utility program that prints 
the catalog cards. The maximum line length is 25 characters 
and the maximum number of lines is seven. 



The output of this program is run on continuous 
form pressure sensitive labels which can be applied to either 
book pockets or book (charge) cards. 

Although coding for this program was completed during 
CLR-443, the program was not sufficiently debugged to offer 
labels during the demonstration of services. 

3.11 SELIN LABEL FORMATTER 

The input for the SELIN LABEL FORMATTER is the 
disc file of Selin records output by CLPP. Each input record 
is in the NELINET internal format and contains a call number , 
location symbols if present, a copy number if more than one 
copy is owned, and a volume number if it is a multivolume work 



| 

i © 

IERIC 



88 



60 . 



The program inserts a carriage return after each appropriate 
line segment, and punches a paper tape containing Dura BCD 
character codes which have been assigned for a Selectric 
Orator ball. The Orator ball prints tall slim characters, 
ten characters to the inch, horizontally. (The participating 
libraries prefer these characters to the Pica characters 
output in the MARC I demonstration.) 

Although the record as output by CLPP could be used to 
generate any type of spine label, this program has been de- 
signed specifically for Selin labels. Selin labels cannot 
be printed on line printers, therefore requiring that the 
output of this program be punched paper tape so that it could 
be run on a DURA typewriter with a Selin label attachment. 

As was the case with the POCKET LABEL FORMATTER , 
this program was not sufficiently debugged to offer Selin 
labels during the demonstration of services. 

3.12 PROGRAM STATUS 

With the exception of CLPP and the CARD FORMATTER, 
the programs were running without any detectable bugs at 
the end of the demonstration. CLPP and the CARD FORMATTER 
do contain a number of fugs which affected about 18% of the 
card sets generated during the demonstration. These are 
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considered to be minor bugs in that fixing them would not 
involve any change in program design. 

A bug is considered to be an error in a program when 
the program does not do what it was specified to do. In 
addition to the bugs that exist in these programs, there are 
some refinements, changes in the specifications, that would 
be desirable. The treatment of overprint headings longer 
than three lines was discussed in Section 3.9. Possible 
improvements in PAPER and the REQUEST VALIDATOR are described 
in Section 4.2.1. In addition to these refinements, the 
SMERGE program will have to be modified so that it can 
accommodate the present form of suffixes in the Library of 
Congress cord number and delete records properly. 
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4. DEMONSTRATION OF SERVICES 

Original plans called for beginning the demonstra- 
tion in July with the University of Vermont and gradually 
adding the other libraries throughout the summer, with all 
libraries participating by early September. Difficulties 
were encountered, however, in getting the system running. 

As a result, the formal demonstration did not begin until 
early October, with the libraries transmitting requests once 
a week for five weeks - on October 3th, 15th, 22nd, 27th, 
and November 5th. Requests were transmitted on Wednesday 
mornings, with the exception of the October 27th run, which 
was moved up to Monday so that visitors from the Council 
of Library Resources might see the operation. 

During the summer, the participating libraries were 
visited by Inforonics' staff and instructed in the use of the 
service. Practice worksheets were filled out, keyed, and 
ti'ansmltted during this visit and then again a few days later 
to familiarize the library staff with the procedure and the 
request format. These "practice" requests were searched 
against the file prior to the October 3th run and the un- 
fulfilled (unmatched) requests were left on the file during 
the demonstration. 
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4 . 1 PROCEDURE 

The procedure was very similar to that followed 
during the MARC I Demonstration. The libraries could submit 
up to 50 requests on October 8th and up to 100 requests on 
October 15th, 22nd, 27th, and November 5th. Tne unx versify 
of Connecticut submitted only 50 requests on each of the 
regular runs because it was submitting a special set of 
requests for 501 items. Although these 501 items were 
current imprints and were expected to be in the MARC II data 
base, they did not represent current processing in that the 
actual volumes had been received by the library some time 
prior to the demonstration period. 

All the requests submitted were for English language 
monographs currently being processed in the participating 
libraries. The point in the library* s processing cycle at 
which the request px*ocedure was inserted varied among the 
libraries and, in some cases, within the library. The manner 
in which each librai*y used the system is explained In 
Section 4.2.2. 

The procedure was as follows (the letter of each 
step corresponds to the letter in the flow chart in Figure 
4-1) : 
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(a) The weekly MARC II tape received from the 
Library of Congress is converted at Inforonics 
into the NELINET internal format. This tape 
is then sent by messenger to the PDP-10 
service bureau (the Interactive Sciences 
Corporation in Braintree , Massachusetts) . 

(b) A cataloger (or clerk in the Catalog De- 
partment) in each library fills out a work- 
sheet for each title according to the speci- 
fied instructions. (See Appendix B.) On this 
worksheet is recorded the request number (a 
number which identifies both the library 
making the request and the request or 
transaction number) , the Library of Congress 
card number, the location, copy, and volume 
information, and the local call number if the 
lihrarjr does m>t desire the one established at 
the Library of Congress. (See Figure 4-2.) 

The libraries can request extra copies of the 
main entry or obtain only one copy of the 
main entry, to use as Library of Congress cata- 
loging copy, if they wish. In the latter case, 
they record an "m" in the block labelled "no mf" 

- no master file - which indicates that the re- 
quest data should not be recorded on the library f s 



NELINET MARC II REQUEST WORKSHEET— UNIVERSITY OF RHODE ISLAND 
Filled in by Teletype Operator: 









no mf 


req<- 


ru69- 


/Jb 





Filled in by Cataloger: 



crd <r 






Location Symbol (s) 


Copy No(s) 


Vol. No(s) 


No Cd 


No S 


No_Bk 


xME 


loc*- 


1 . 


2. 


3. 


4. 


5. 


6. 


7. 


locf* 


1 . 


2. 


3. 


4. 


5. 


6. 


7. 


locf 


1 . 


2. 


3. 


4. 


5. 


6. 


7 . 


loc<- 


1 . 


2. 


3. 


4. 


5. 


6. 


7. 


loc* 


1 . 


2. 


3. 


4. 


5. 


6. 


7. 


locf 


1 . 


2. 


3. 


4. 


5. 


6. 


7* 


locf* 


1 . 


2. 


3. 


4. 


5. 


6. 


7. 


loo*- 


1 . 


2. 


3. 


4. 


5. 


6. 


7. 



call^« 



Valid Location Symbols 



Archiv 

Blatz 

EXT 

J.F.K. 

racard 

mfiche 



mfilm 

NML 

R.I.C1 

Rare 

Ref 
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holdings file. The request format was designed 
to leave as little room for error as possible by 
reducing to a minimum the data the libraries 
inputted. When the libraries want products 
for a single copy for the main stacks of the 
main library, for example, they do not record 
anything in the "loc" field. The recording pro- 
cedures for other conditions are described in 
Appendix B. 

(c) The Teletype operator types the information 
recorded on the worksheet according to the 
typing instructions described in Appendix C. 

This typing is done off-line on a model 33ASR 
Teletype and produces a punched paper tape and 
a teletypewriter listing. (See Figure 4-3.) 

(d) The Teletype operator places the punched paper 
tape in the reader at the time specified for 
transmission. If the machine has the ’'Automatic" 
feature, the operator sets the switch to 
Automatic. Inforonics initiates the transmission 
by calling the library. The transmission then 
proceeds automatically. If the library does not 
have the Automatic feature on its Teletype, 

the operator must push the start switch after 
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RHQe RUS9-12 
CRD <r 69-10602 

w 



FIGURE 4-3 
TELETYPE REQUEST 
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Inforonics calls. The operator is near by 
during the transmission to insure that the paper 
tape does not get tangled and jam in the reader. 
The Teletype at Inforonics produces a punched 
paper tape and a listing of each library's 
requests. In the MARC I demonstration, the 
libraries initiated the transmission by calling 
any time during the morning. Since the Tele- 
type at Inforonics is also used by the Inforonics* 
programmers to debug their programs, in this 
demonstration, Inforonics initiated the trans- 
mission so as not to tie up the Teletype any 
longer than necessary. 

(e) Inforonics transmits the requests via its 
Teletype to the PDP-10 service bureau in 
Braintree. The libraries could ti-anemit direct- 
ly to the service bureau and may do so eventual- 
ly when all the problems have been worked out 
and the operation is running smoothly. 

(f) The requests and new bibliographic records are 
put through a series of programs on the PDP-10 
that search the file and for those records 
found, (both the new requests and the requests 
from previous runs that are matched in the 
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new tape) outputs a magnetic tape containing 
catalog card images. (These programs are des- 
cribed in detail in section 3.) Error and 
"not found” messages are also typed out. The 
programs necessary to produce Selin labels and 
pocket labels were not sufficiently debugged to 
offer these products during this demonstration. 

(g) The output magnetic tape from step (f) is 
taken by messenger to the Information Services 
Inc. service bureau in Wellesley, Massachusetts, 
where it is printed onto continuous form card 
stock, using an IBM 1403 line printer, driven 

by a 360/40 computer, with an upper and lower 
case print train with the IBM TN character . 

(h) A librarian at Inforonics proofreads the 
catalog cards, noting all program bugs and 
possible input errors in the Library of 
Congress data on the Teletype listing of the 
requests. A problem report (see Figure 4-4) 
is made out for each input error and new 
program bug. Copies of reports describing 
possible errors in Librax'y of Congress data 
are sent to the Library of Congress. The 
error messages generated by the computer 
programs are reviewed and any errors in the 
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Date: Oaf ■ ' 


• n 

71. 

Req. No.: £f V b> ^-2-% lOCLl 


From: / C. 


LC Card No. : ^ / !? 2)4" 


Library: " * 

Description of Problem: (attach 


sample if possible) 




/V f~T J^uz^e. - 













n - is 



f 

TA 

418. 9 

C6 

D48 



Dietz, Albert George Henry, 1908- 
Composite engineering laminates, 
edited by Albert G. H. Dietz, . 
Cambridge, Mispress [ 1969 ] 
vii, 328 p. illus. .29 cm. 
Includes bibliographies. 

1 • Composite materials — Addresses, 
essays, lectures. .2. Laminated 
materials — Addresses, essays, 
lectures. I.T. 



CtU69- 281021 
TA418.9.C6D48 



68-18234 

620.1/1 



Suggested Improvement : 




Send To': Miss Ann T. Curran 

Inforonics, Inc. 

I 146 Main Street 

! . Maynard, Massachusetts 01754 

FIGURE 4-4 

O • PROBLEM REPORT 
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requests are noted on the Teletyne listing. 
Statistics on the number of card sets that 
contain bugs and other errors are recorded 
along with the statistics generated by the 
programs . 

(i) The catalog cards are then mechanically cut 
by the NIKOR card cutter at Inforonics. 

( j ) The catalog cards (see Figure 4-5) are mailed 
to the libraries along with the annotated 
Teletype listings. 

(k) The libraries review the cards and send back 
problem reports to call attention to any 
imperfect cards Inforonics did not catch 
and also to give their opinions about the 
format of the cards. 

(l) Inforonics* staff reviews the reports sent 
in by the libraries, registers them, and 
responds to the libraries when appropriate. 

4.2 RESULTS 



In summary, a total of 2317 requests was submitted 
by the libraries for which 1349 MARC records were found. 
Included in these 2317 requests are the 248 requests submitted 





The Goulds. . 
GOULD FAMILY. . 

GOULD, JAY, 1836-1892. . 



CT Hoyt, Edwin Palmer. 

275 The Goulds; a social history, by 

G6 Edwin P. .Hoyt. New York, Weybright 

H63 and Talley [ 1969] 

1969 vi, 346 p. illus., ports. .25 cm. . 

1. Gould, Jay, 1836-1892. .2. Gould 
family. I.T. 



RU69-12 v ••) 69-10602 

CT275.G6H63 1969 929.2/0973 
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HD Employment and educational services in 

6275 tne Mobilization for Youth 

N4 experience. Edited by Harold H. 

E45 Weissman. New York, Association 

Press [ 1 969 ] 

22.4 p. 21 cm. (The New social work, 
3) 

Bibliographical footnotes. . 

1. Youth: — Employment — New York (City) 
2. Occupational training — New York 
(City) 3. Education— New York (City) 



HD Employment and educational . services in 

6275 the Mobilization for Youth. ... 1 969 

N4 (card 2) 

E45 4. Mobilization for Youth. I. Weissman, 

Harold H., ed. I I. Mobilization for 
Youth. 



CtU69-3000 14 
HD6275.N4E45 



69-18845 

331.3/4/097 



FIGURE 4-5b 

CATALOG CARDS WITH CONTINUATION HEADER 
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during the practice sessions, the 1568 submitted during the 
official runs (October 3 , 15, 22 , 27, and November 5), and 

t 

the 501 submitted in the University of Connecticut's special 
request . 



Production summaries for each of the five participat- 
ing libraries are presented in Tables 4-la and 4- lb. 

4.2.1 Requests Rejected 

174, or 7.5% of the requests transmitted were rejected. 
Although the usual procedure was not to correct the requests, 
but just to point out the error on the Teletype listing re- 
turned to the libraries, an exception was made for the Univer- 
sity of Connecticut's special request for 501 backlog items. 

The 17 requests that were rejected in this batch were rekeyed 
and resubmitted by Inforonics and searched in the next run. 

13 of these 17 rejected requests were rejected because a "/" 
was keyed Instead of "\" in signaling the deletion of lines 
and records. 

About half of all rejects were caused by errors 
in keying or format, and half were caused by poor trans- 
mission. The errors due to poor transmission were not 
evenly distributed among the libraries. New Hampshire's 
transmissions accounted for more than half of them. There 
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Connecticut 


Massachusetts 


New Hampshire 


Rhode Island 


Vermont 


Total 


Requests Sent 


790 


300 


511 


336 


380 


2317 


Requests Rejected 


37 


8 


75 


11 


43 


174+ 


Requests Searched 


770 + 


292 


436 


325 


347 


2170+ 


Requests Not Fount 


41 


144 


228 


251 


157 


821 


Requests Found 


729 


148 


208 


74 


190 


1349 


Acceptable 


59b 


109 


159 


67 


167 


1097 


Unacceptable 


134 


39 


49 


7 


23 


252 



TABLE 4-la 

PRODUCTION SUMMARIES 





1 

1 

| Connecticut 

f 

[ . . 


1 

j 

Massachusetts 


New Hampshire 


Rhode Island 


Vermont 


Total 


Requests Sent 


790 


300 


511 


336 ; 


380 


2317 


Requests Rejected 


4.7 


2.7 


14.7 


3.3 ! 


11.3 


7.5+ 


Requests Searched 


97.5+ 


97.3 


85.3 


96.7 


91.3 


93.7+ 


Requests Not Fount 


*5.3 


49.3 


52.3 


77.2 


45.2 


37.8 


Requests Found* 1 


94.7 


50.7 


47.7 


22.8 


54.8 


I 62.2 


Acceptable** 


81.6 


73.6 


76.4 


90.5 


87.9 


81.3 


Unacceptable** 


18.4 


26.4 


23.6 


09.5 


12.1 I 


1 18.7 



+The 17 requests that were rejected in Connecticut *s special 
request for 501 backlog items were keyed and resubmitted by 
Inforonics. 10 of Vt T s practice rejects were also resubmitted 
♦Percent of Requests Searched ** Percent of Requests Found 

TABLE 4-lb 

PRODUCTION SUMMARIES - PERCENT 




1G5 



was so much trouble in receiving the October 22 requests from 
New Hampshire that the tape for the next run was mailed 
rather than transmitted over the Teletype. The machine at 
New Hampshire was serviced by the telephone company and 
transmission improved somewhat for the November 5th run. 

Busy circuits also caused trouble in getting through 
to the libraries. Initially the schedule was set up with 
Inforonics calling the library at a specified time on 
Wednesday morning. Inforonics found it could not keep to 
the schedule because it sometimes took six or more attempts 
to reach a library. The procedure was changed with all the 
libraries set up to transmit anytime from 10:00 to 12:00 
on Wednesday morning. The libraries were called in alpha- 
betical order. If there was trouble in reaching one library, 
the next on© was tried, coming back later to the other library. 

The format la simple and was quickly learned. How- 
ever, errors continued to occur throughout the domonatraLion , 
suggesting that keyboarding errors are a function of key- 
boarder accuracy rather than length of experience with the 
system. Some of the errors were miskeyings — i.e., striking 
the wrong key. Others were errors in format, e.g ., forget- 
ting to key the characters required to end a i*ecord before 
beginning the next record. 
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The verification routines in the REQUEST VALIDATOR 
(described in Section 3.4) are aimed at catching both keying 
and format errors. They presently catch almost all of the 
format errors and a good number of keying errors. They also 
catch most of the errors due to poor transmission. With the 
addition of a verification routine on local call numbers to 
check that not more than six characters are present within the 
slashes that indicate line segments, virtually all of the 
format errors affecting card production that were noticed in 
the demonstration run would be caught. 



\ 

i 

i 

i 

i 

I 

i: 

I 

V 




All keying errors, on the other hand, could not be 
caught by verification routines. The verification routines 
presently catch a large number of keying errors. A few more 
could be added that would catch others. However, a miskeying 

r 

in a local call number, e.g., a 7 for a 6 somewhere in a 
Dewey class number, could not be caught. At present, the 
sequence number in a Library of Congress card number is not 
verified, but it could be for new card numbers by using the 
check digit. Errors made in assigning or keying the request 
number could also be caught by sequence checking the request 
number . 

i 

Whereas the variety of characters that can occur in 
bibliogi*aphlc data make error detection by character verifi- 
cation almost impossible, character verification of the possi- 
ble characters in the data elements in a request can catch 
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most of the errors. Programmers (and programs) like to deal 
in terms of never and always. With bibliographic data one 
can never say never and less frequently can one say always. 

The data elements in requests, however, are mainly for con- 
trol purposes and are not concerned with bibliographic des- 
cription. Most of the determinations of valid and invalid 
characters for a data field can be made when the system is 
designed. Experience in running the system can indicate ad- 
ditional ones that would be useful and also which checks are 
too restrictive. For example, the verification routines for 
local call numbers do not consider brackets a valid character 
in a local call number. In the demonstration they occurred 

once. Since they can occasionally occur, the routine will 

/ 

have to be loosened to accept /brackets . 

Much time can be spe'nt when designing a validating 
program in trying to predict the kinds of errors that might 
be made in inputting a new format. It takes operating ex- 
perience, however, to really see what people will do to a 
system. The first objective is to catch the errors. The 
next objective is to avoid repetition of the error, if 
possible. If that is not possible, the objective is to second 
guess what the data should have been. If neither of these 
approaches is possible, the next objective is to let the 
library know what the error is. 
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Avoiding the error is the most desirable solution if 
it is possible. The input code for the University of Connec- 
ticut is CO. In one of the early transmissions, the number 
0 was keyed instead of the letter 0. This request was 
therefore rejected. Staff at the University of Connecticut 
suggested that their input code be changed to CT. This was 
a good suggestion. It would mean a change in the REQUEST 
VALIDATOR to accept CT as the valid code — not a difficult 
change. It would, however, also have other implications. 

The CARD AND LABEL PRODUCTION program uses the input code 
to get into the library's profile specifications. The input 
code in this program could also be changed without much 
difficulty. There would, however, be unfulfilled requests 
with the library code CO already on the cumulative file. 

The program would have had to be modified to accept either 
code. Since the demonstration was to last only a few weeks, 
it was decided not to make this change during the demonstra- 
tion. This example also illustrates the point that in 
automated eys terns, very little is Simple. 

Operating experi nnoo sliowud -that tins character 

used as tho control character, the backslash "\" , was error 
prone. This character is to signal that an editing command 
follows and also to terminate each request. In the October 
8th run, one of the libraries used the regular slash "/" to 
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end each request. All of these requests were rejected. On 
another day, another library keyed "/KL" instead of "\KL" when 
they wanted to kill (delete) a line. These requests were 
rejected. 

One solution is to find another character instead 
of the "Y\ Another would be to substitute a "V* for a "/” 
whenever the "/" is not valid. This would work for ending 
requests since it takes two backslashes " \\" to end a request 
and two regular slashes are not expected in the data. Single 
slashes, however, do occur in local call numbers to separate 
the line segments, in location statements to separate location 
symbols, and in Library of Congress card number suffixes. 

The programming required to second guess correctly about 
substituting "\" for "/” would not be insignificant. A 
better approach would be to find another control character. 
Presently the character on the teletypewriter Indicates 
an upper case shift, the separates tags or labels from 
data fields, and the "$*' Indicates that the copy and volume 
ranges that follow are to be enumerated in label production - 
which leaves few characters remaining to choose from. 

The wide variety of errors detected by the REQUEST 
VALIDATOR are not presently matched by a correspondingly wide 
variety of error messages because the REQUEST VALIDATOR is 
catching errors that were not considered when the program 
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was designed. As a result some of the error messages put out 
are difficult to interpret. In the demonstration, the error 
messages were interpreted by Inforonics' staff and then 
described on the annotated copies of the Teletype listings 
returned to the libraries . Now that there is some knowledge 
of the kinds of errors made, the machine output error messages 
can be improved so that they would be understandable to the 

libraries . 

i 

i 

\ 

4.2.2 Records Found on the MARC File 

As shown In Tables 4-la and 4-lb, 1349 or 62.2% 
of all requests searched were found on the IIARC File, there 
was, however, a wide range of difference naoac t the libraries, 
with Connecticut finding the largest percent of searched 
requests (94,7%), Rhode Island finding the least (22.8%), 
and the other libraries achieving a hit rate of between 47* 

and 59%. 

In addition to total production figures , additional 
statistics on the number of records found on the MARC file 
were obtained for the five official runs, l.e., October 8th, 

15th, 22nd, 27th, and November 5th. These figures are shown 
In Tables 4-2 through 4-7 . The number and percent of reco 
that were on the file when the requests were Initially sub- 
mitted and those that appeared 1, 2, 3, and 4 weeks later are 
presented along with the totals for each Institution for 
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Library 


Connecticut 


Massachusetts 


New Hampshire 


Rhode Island 


Vermont 


Total 


Requests Searched 


231 


261 


382 


304 


258 


1436 


Found '.’hen Run 


190 


100 


127 


38 


186 


649 


Found 1 Wfc. Later 


11 


6 


7 


5 


0 


29 


Found 2 r ./ks. Later 


4 


11 


15 


6 


1 


37 


Found 3 Wks. Later 


0 


5 


14 


4 


0 


23 


Found 4 Wks. Later 


0 


2 


3 


1 


0 


6 


Total 


213 


124 


166 


54 


187 


744 



TABLE 4-2 a 

RECORDS FOUND - OFFICIAL DEMONSTRATION RUNS 

SUMMARIES 



Library 


Connecticut 


Lassachusetts 

■ 


pew Hampshire 


phode Island 


Vermont 


Total 


Requests Searched 


231 


261 


382 


304 


258 


1436 


Found When Run 


85.7 


37.9 


33.2 


12.5 


72.1 


45.2 


Found 1 Wk. Later 


6.0* 


2.7* 


2.4* 


2.0* 


0* 


2.8< 


Found 2 Wks. Later 


2.8* 


5.4* 


7.8* 


4.5* 


* 

CO 

• 


4.74 


Found 3 Wks. Later 


0* 


3.5* 


11.2* 


5.1* 


0* 


4.6* 


Found 4 Wks. Later 


0* 


4.5* 


6.8* 


2.9* 


0* 


3.74 


Total 


92.2 


47.5 


43.5 


17.8 


72.5 


51,8 



*See footnote on Table 4-3b 



RECORDS 



if 
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TABLE 4-2b 

FOUND - OFFICIAL DEMONSTRATION RUNS 
SUMMARIES - PERCENT 
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i 

j 

i 

! 

| 

i 

i 

i 

} 

* 

t 



i 

i 

1 

\ 



i 

! 

I 

! 

t 

i 

I 

i 

i 



t 

i 

I 

t 

L. 

■ - 




Date Of Transmission 


October 

5 


October 

15 ?» ' . 


October 

22 


October 
• * -27 


. November 

! 5 ' 




i 

1 

i 

H 

a 

p 

• 


Requests Searched 


44 


48 


50 


41 


48 


231 


Found When Run 


34 


46 


47 


32 


39 


198 


Found 1 Wk. Later 


6 


1 


0 


4 


- 


11 


Found 2 Wks. Later 


4 


0 


0 


- 




4 


Found 3 V/ks. Later 


0 


0 


— 


— 


- 


0 


Found 4 Wks. Later 


0 


- 






- 


0 


Total 


44 


47 


47 


36 


39 


213 



TABLE 4-3a 

RECORDS FOUND - OFFICIAL DEMONSTRATION RUNS 
UNIVERSITY OF CONNECTICUT 



Date of Transmission 


October 

3 


October 
_ 15 


October 
. 22 


October 

27 


November 

5 


•Total 


Requests Searched 


44 


48 


50 


41 


48 


231 ’ 


Found When Run 


77.3 


95.8 


94.0 


78.0 


81.3 


85.7 


Found 1 Wk. Later 


13.6 


2.1 


0 


9.8 


- 


6.0* 


Found 2 Wks. Later 


9.1 


0 


0 


- 


- 


2.8* 


Found 3 Wks. Later 


0 


0 


- 


- 


- 


0* 


Found 4 Wks. Later 


0 


- 


— 


— 


- 


0* 


Total 


100 


97.9 


94.0 


07.8 


81.3 


| 92.2 i 



*Percent of total requests searched initially, whose "not 
found" requests were still on the active search file. Dashes 
indicate requests were not on the active file that week. 



TABLE 4-3b 

RECORDS FOUND - OFFICIAL DEMONSTRATION RUNS 
UNIVERSITY OF CONNECTICUT - PERCENT 
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Date of Transmission 


October 

8 


October 

15 


October 

22 


October 

27 


November 

5 


Total 


Requests Searched 


44 


100 


61 


18 


38 


261 


Found When Run 


10 


44 


24 


7 


15 


100 


Found 1 Wk. Later 


2 


3 


1 


0 


- 


6 


Found 2 Wks. Later 


4 


4 


3 


- 


- 


11 


Found 3 Wks. Later 


1 


4 


- 


- 


- 


5 


Found 4 Wks. Later 


2 


— . 




- 




2 


Total 

- ■ 


19 


55 


28 


7 


15 


124 : 



TABLE 4-4a 

RECORDS FOUND - OFFICIAL DEMONSTRATION RUNS 
UNIVERSITY OF MASSACHUSETTS 



Date of Transmission 


October 
| 8 


October 

15 


October 

22 


October 

27 


November 

5 


Total 


Requests Searched 


44 


100 


61 


18 


38 


261 


Found When Run 


22.7 


44 


39.3 


38.9 


39 • 5 


37.9 


Found 1 Wk. Later 


4.5 


3 


1.6 


0 


- 


2.7* 


Found 2 Wks. Later 


9.1 


4 


4.9 


- 


- 


5.3* 


Found 3 Wks. Later 


2.2 


4 


- 


- 


- 


3.5* 


Found 4 Wks. Later 


4.5 


- 


“ 




wm 


4.5* 


Total 


43.2 


55 


45.9 


38.9 


39.5 


! 47.5 

i 



♦Percent of total reqpests searched initially, whose "not 
found 11 requests were still on the active search file. Dashes 
indicate requests were not on the active file that week. 



TABLE 4 -4b 

RECORDS FOUND - OFFICIAL DEMONSTRATION RUNS 
UNIVERSITY OF MASSACHUSETTS - PERCENT 
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Date of Transmission 


October 

8 


October 

15 


| October 

I 22 


October 

27 


1 

0 IO 
> 

5§ 


Total 


Requests Searched 


44 


81 


68 


97 


92 


382 


Found When Run 


18 


23 


27 


40 


19 


127 


Found 1 Wk. Later 


0 


3 


3 


1 


f 


7 


Found 2 Wks. Later 


6 


4 


5 


- 


- 


15 


Found 3 Wks. Later 


1 


13 


« 4 


- 


- 


14 


Found 4 Wks. Later 


3 


- 


- : 


- 


- 


3 


Total 


28 


43 


35 


41 


19 


166 



TABLE 4-5a 

RECORDS FOUND - OFFICIAL DEMONSTRATION RUNS 
UNIVERSITY OF NEW HAMPSHIRE 





(4 


P 


u 


p 


i ' 


I 

1 

i 


Date of Transmission 


2 


O 

S3 Ift . 


0 

X> CQ 


o 

ON 


iH 




O CO 


0 H 


0 N 


0 CO 


0 lO . 


Ct 




•p 


P 


P 


+» 


> : 


4-> 




o 


O 


O 


o 


0 


p 




o 


O 


O 


o 


53 


H 


Requests Searched 


44 


81 


68 


97 


92 


382 ? 
1 1 


Found When Run 


40.9 


28.4 


39.7 


41.2 


20.6 


33.2 


Found 1 Wk. Later 


0 


3.7 


4.4 


1.0 


- 


2.4* 


Found 2 Wks. Later 


13.6 


4.9 


7.4 


- 


- 


7.8* 


round 3 Wks . Later 


2.2 


16.0 


- 


- 


- 


11.2* 


Found 4 Wks . Later 


6.8 


“ 


“ 






6.8* 


Total 


63.6 


53.1 


51.5 


42.3 


20.6 


43.5 : 



^Percent of total requests searched initially, whose "not 
found" requests were still on the active search file. Dashes 
indicate requests were not on the active file that week. 



TABLE 4-5b 

RECORDS FOUND - OFFICIAL DEMONSTRATION RUNS 
UNIVERSITY OF NEW HAMPSHIRE - PERCENT 
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— 
Date of Transmission 


October 

8 


October 

15 


October 

22 


October 

27 


November 

5 


Total 


Requests Searched 


35 


44 


54 


42 


129 


304 


Found When Run 


8 


9 


8 


2 


11 


38 


Found 1 Vk. Later 


0 


1 


1 


3 


— 


5 


Found 2 Wks. Later 


1 


2 


3 




m 


6 


Found 3 Wks. Later 


0 


4 




mm 




4 


Found 4 Wks. Later 


1 


- 


- 


- 


- 


1 


Total 


10 


16 


12 


5 


11 


54 

. - ■ - -- - - 



TABLE 4-6a 

RECORDS FOUND - OFFICIAL DEMONSTRATION RUNS 
UNIVERSITY OF RHODE ISLAND 











j 

t 


| 

1 

u 






h 


(4 


u 


u 


4) 




Date of Transmission 


O 

o CO 


0 

X3 to 

0 IH 


l Sea 

O 


.8 o* 
O 03 


0 

o to 


fH 

at 




+» 


+» 


•v» 


■¥» 


> 


+» 




o 


0 


o 


O 


o 


O 




o 


O 


o 


o 


S5 


6* 


Requests Searched 


35 


44 


54 


42 


129 


304 


Found When Run 


22.9 


20.5 


14.8 


4.8 


8.5 


12.5 


Found 1 Wk. Later 


0 


2.3 


1.9 


7.1 


l 


2.9* 

4.5* 


Found 2 Wks. Later 


2.9 


4.5 


5.6 


— 




Found 3 Wks. Later 


0 


9.1 


- 


— 


- 


5.1* 


Found 4 Wks. Later 


2.9 


- 


- 


- 


mm 


2.9* 


Total 


28.6 


36.4 


22.2 


11.9 

1 . . - 


8.5 

l i 


17.8 



♦Percent of total requests searched Initially, whose "not 
found" requests were still on the active search file. Dashes 
indicate requests were not on the active file that week. 
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RECORDS FOUND - OFFICIAL DEMONSTRATION RUNS 
UNIVERSITY OF RHODE ISLAND - PERCENT 
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Date of Transmission 


October 

8 ; 


October 

15 


• 

October 

22 


October 

27 

i 


! November 

1 5 

1 


rt 

rt 

■P 

o 


Requests Searched 


31 


32 


56 


46 


93 


258 


Found When Run 


18 


26 


45 


36 


61 


186 


Found 1 Wk. Later 


0 


0 


0 


0 


— 


0* 


Found 2 Wks. Later 


0 


1 


0 


- 


- 


1* 


Found 3 Wks. Later 


0 


0 


- 


- 


- 


0* 


Found 4 Wks. Later 


0 


— 


- 


— 




0* 


Total 


18 


27 


45 


" 36 


! 61 


187 



TABLE 4-7a 

RECORDS FOUND - OFFICIAL DEMONSTRATION RUNS 
UNIVERSITY OF VERMONT 
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Date of Transmission 


i 

October 

8 


October 

15 

i 


October 

22 


October 

27 


November 

5 


Total 


Requests Searched 


31 


32 


56 


46 


93 


258 


Found When Run 


58.1 


81.3 


80.4 


78.3 


65.6 


72.1 


Found 1 Wk. Later 


0 


0 


0 


0 


. » 


0 * 


Found 2 Wks. Later 


0 


3.1 


0 




- 


.8 


Found 3 Wks. Later 


0 


0 


- 


- 




0 * 


Found 4 Wks. Later 


0 




“ 




*• 


0 * 


Total 


58.1 


84.4 


80.4 


78.3 


65.6 


72.5 



found" requests were still on the active search file. Dashes 
indicate requests were not on the active file that week. 

TABLE 4-7b 

RECORDS FOUND - OFFICIAL DEMONSTRATION RUNS 
UNIVERSITY OP VERMONT - PERCENT 
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each run. The requests submitted during the practice sessions 
were eliminated from this analysis because it was suspected 
that the libraries did not use the system in the practice 
sessions as they did during the five official runs. Com- 
parison of the percent of records found in these five runs as 
shown in Table 4-2b with the totals for the entire demonstra- 
tion presented in Table 4-lb indicates that this was true 
for most of the libraries . The greatest difference was ex- 
hibited by the University of Vermont. When their practice 
requests are included as they ere in Table 4-lb, their hit 
ratio is only 54. G%. When the practice requests are excluded, 
the hit ratio rises to 72.5%. The University of Connecticut's 
special request for 501 backlog items was excluded because it 
would give a distorted picture of the number of records that 
might be expected to be found when initially searched and in 
each succeeding week's run. 

The newness of the MARC service (six month's accumu- 
lation) , the limited number of demonstration runs, and the 
high probability that the libraries were not using the system 
as they would in a full scale production operation (in which 
they would submit requests for everything that might be on 
the MARC file), make grand attempts at interpretation of the 
BfcAt.lst.iop gathered rather foolish. Therefore, tho otntist.tcs 
are presented for each run for each library, without inter- 
pretation, but. with a dto'uipfllon of the factors that may 
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have affected the hit ratio, and of the practices that were 
followed by each library in deciding for v/hat to submit 
requests . 



As Table 4-2b indicates, there is still a v/ide range 
of differences with Connecticut again having the largest 
percent of hits (92.2%), Rhode Island the least (17. G%), 
and Massachusetts, New Hampshire and Vermont finding 47.5%, 
43.5%, and 72.5%, respectively, of their requests. 

Since all the libraries wore submitting requests for 
current English language monographs, one night expect that 
all requests submitted would be found on the file. That they 
did not can be attributed to four factors: (1) the^newness" 

of the file - it contained an accumulation of only six months 
processing of English language monographs printed in this 
country and three months accumulation of English language 
monographs printed elsewhere; (2) the currency of cataloging 
and MARC II editing at the Library of Congress; (3) the 
pattern of book selection and ordering at the individual 
libraries; and (4) the point in the processing cycle at which 
the libraries chose to submit their requests. This last 
factor may be influenced by the classification scheme used 
by the library. If the library does not use Library of 
Congress classification, it must wait until a classification 
number is assigned the book before requesting cards in order 
to receive cards that contain their call number • 




119 



91 . 



I 



" O 

ERIC 



The MARC distribution service began late in March, 
X969, and had a six month's accumulation, some 20,000 records, 
on it when the demonstration began in October. At the end of 
the demonstration, it contained almost 28,000 records. Records 
for American imprints cataloged by the Library of Congress 
prior to March, 1969 and non-American English language im- 
prints cataloged before July, 1969 were not on the filo. 

Even though the scope of coverage for MARC II is well defined, 
records for some current English language monographs will not 
be found on the MARC file because the monographs woro cataloged 
at the Library of Congress before the MARC II distribution 
service began. As one goes on in time, the percent of a 
library's current processing included in this catagory could 
be expected to diminish. 

A library's selection and ordering practices also 
affect the percentage of hits. Books received on standing 
order plans may not yet have been cataloged by the Library of 
Congress when the libraries submit their requests. Faculty 
suggestions for purchase, on the other hand, though for new 
books, may not be for ones that have Just been issued by 
the publishers, and therefore have a better chance of being 
found . 



Added to the possible variations in libraries' 
selecting nnd ordtnH ng practices are the variations in the 
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time chosen in the processing cycle to enter a request. A 
library nay subnit requests immediately upon recoipt of the 
books. If this procedure is used for books received on 
standing order, a low hit rate is understandable. 

A library may submit requests for books before, or 
after, searching for Library of Congress cataloging copy. 

If it submits requests after searching for Library of Congress 
copy it may choose, in a demonstration such as this one, to 
enter requests only for those items for which there was an 
indication on the Library of Congress cataloging copy that 
the record was on the MARC file. It might also choose to 
submit requests for items for which it could find no Library 
of Congress copy. In these cases whether or not the library 
roceives Library of Congress proof slips would have an 
influence on the number of records found. If it does receive 
proof slips, it is submitting requests for iiewei* books than 
if it were in tho National Union Catalog only. 

If a library waits to submit requests until after it 
has cataloged a book, one would expect to find a larger 
percent of the records on the file because more time has 
elapsed since the book was first released . 
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Finally, the decision of what to submit nay be 
influenced by the amount of work in the library that can be 
eliminated by the system-gonerated products. If, for example, 
the library docs not have Library of Congress cataloging copy , 
the searching operation a3 well as catalog card preparation is 
eliminated by use of the syston. If It already has the cata- 
loging copy, and if it has ample personnel for catalog card 
preparation, it might not request the catalog cards from the 
system. Likewise, if a library’s searching staff is ample 
but the catalog card preparation staff somewhat limited, the 
library might choose to submit requests which it knows are 
on the MARC file and for which the system would therefore 
generate catalog card sets. When a library is submitting the 
maximum number of requests allowed, its decision is based on 
getting what will be most useful to it from the system. When 
a library is not submitting the maximum number of requests, 
its decision to use the system only for items that will save 
it a large amount of effort is influenced perhaps by the 
librarian’s frugal nature which has developed from years of 
necessity! 

Any or all of these factors nay have been present 
in this demonstration. The libraries were instructed only 
on the number of requests to submit each week. With the 
exception of the University of Connecticut, the libraries 
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could submit up to 50 requests in the first transmission on 
October Oth, and up to 100 in each of tho four other trans- 
missions. The University of Connecticut was instructed to 
limit transmissions to 50 requests since it was also submit- 
ting its special request for 501 non-current items. Only tho 
University of Connecticut submitted the maximum number of 
requests that they were allowed in each transmission. 

The University of Connecticut used tho system for 
standing orders for which it had recoivod Depository Cards 
bearing the indication that the record was on tho MARC file. 
If a Depository Card is not found when the book is received, 
a copy of the order form is placed in the file to catch the 
Depository Card when it is received. 

As indicated in Table 4-2b, Connecticut received 
92% of the requests searched during the five official runs. 
One would have expected them to find all. This discrepancy 
was discussed with the Library of Congress, and it was found 
that it is possible to have a card with MARC indicated on it 
before the record is actually oil the MARC file. 

T 

\ 

The University of Massachusetts had already found 
proof copy for some of its request^. Other requests were for 
titles for which they had not received proof slips. The 
November 5th run was almost entirely for titles for which 
they did not have proofslips. 39.5% of its requests in the 
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November 5th run and an overall average of 47 . 5% of its 
requests were found. 

The University of New Hampshire used the system 
largely for items for which it had not found proof copy. In 
some coses it found that it actually had the proof copy but 
had not searched for it under the cataloged main entry. It 
found 43.5% of the requests searched during the official 
demonstration runs. 

The University of Rhode Island used the system for 
items for which it could not find Library of Congress copy 
using the Information Dynamics Corporation microiicho 
service. It found only 17.8% of the requests searched 
during the official runs. 

The University of Vermont is the only participating 
library that does not use Library of Congress classification. 
It must assign a Dewey classification number and input its 
call number in its requests to generate complete card sets 
containing the University of Vermont call number. This it 
did for some items. It also used the system to obtain 
Library of Congress cataloging copy for titles that were not 
yet in the National Union Catalog . It does not receive 
Library of Congress proof slips. With a couple of additions 
to the request worksheet (see Appendix B, page B-7) , the 
system will generate one copy of the main entry instead of a 
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conplete set of cords. Vermont found 72.5% of the requests 
searched during the official demonstration runs. 

The NBLINET MARC II system was designed to retain 
unfulfilled requests on the file and search each new batch 
of records for these items. During the demonstration period, 
the MARC file searched was not a conplete up-to»-date MARC 
file because two of the recently received MARC tapes had to 
be returned as unusable and because two other of the recently 
received tapes wore large and could not be sorted at the 
service bureau due to a bug in its system. The oug was 
fixed, usable copies of the two bad tapes were obtained, and 
every unfulfilled request was then searched against the com- 
plete MARC file before the demonstration terminated. 

The card sets generated at this time from these 
previously unfulfilled requests were then checked against 
the lists of Library of Congress card numbers on the MARC 
file that came with the tapes. Determinations were then made 
as to whether the card set would have been generated when the 
request was first searched or run or whether it would have 
been generated 1, 2, 3, or 4 weeks later. The results are 
shown in Tables 4-2 through 4-7. Again, since the number 
of requests and runs are small, little can be interpreted 
from these figures. 
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4. 2. 2.1 Comparison of MARC I and MARC II Hit Ratios 

Statistics were collected for the lapt two months 
of the MARC I demonstration. 53.1% of the requests eearchod 
during this period were found on the MARC I file. Since the 
KELINET MARC I system did not retain unfulfilled requests on 
the file to be searched against new records, all of these 
requests were found when the request was first submitted. 

In the MARC II demonstration, a total of 62.2% of 
all requests searched were found. In the five official runs, 
however, only 51.3% of the requests searched were found. 
Included in this 51.3% are the records found 1, 2, 3, and 4 
weeks later. 

4. 2. 2. 2 Conclusion 

Of the records not found when searched, it would be 
expected that some would never appear on the file because they 
are not included in MARC II's coverage. It is conceivable 
that the libraries could mistakenly submit a request for a 
book that could not be on the MARC II file, but since it is 
easy to determine whether a book is a current English language 
imprint it is unlikely that this would happen very often. 

It is more probable that the reason for most of this type 
of not found is that the book was cataloged at the Library 
of Congress prior to the time when MARC II records were 
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prepared for this type of material — for American imprints 
if it was cataloged before the end of tiarch, 1969, and for 
English language monographs printed outside this country, if 
it was cataloged before July, 1969. As one goes on in time 
with a MARC file, one would expect that a library’s current 
processing would be affected less and less by this factor. 

Of the requests that were ’’not found" that are uot 
in the category of "not founds" described above, the reason 
for their not being found must be that they not cataloged 

or MARC edited by the Library of Congress in tine to be on 
the MARC file during this demonstration. This would suggest 
that if the Library of Congress processing conditions during 
this demonstration, i.e., the backlog in the cataloging or 
MARC editing, were typical of what night ,be expected, 
leaving the unfulfilled requests on the file for more than 
four weeks might produce a significantly larger number of hits. 

However, in summary it should again be pointed out 
that although the statistics obtained in this demonstration 
may be interesting, they are not in fact meaningful indicators 
of the coverage of the MARC II tapes in relation to a library’s 
current processing. To gain meaningful statistics, a library s 
total current processing would have to be considered, and 
oyer a longer period than five weeks. What the experience 
gained during CLR-425 and CLR-443 has pointed out is that the 






picture changes from library to library depending on the 
library's purchasing and processing practices. 
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4.2.3 Card Sets Generated 

Of the 1349 records found, 31.3% of the card sets 
generated were considered acceptable and 13.7% were con- 
sidered unacceptable when proofread by Inforonics’ staff. 

This resulted in the libraries receiving acceptable card 
sets for 47.3% of the requests submitted during this demon- 
stration. Bugs in the programs accounted for over 90% of the 
unacceptable card sets. Errors in the input data on the 
MARC tapes accounted for a small number of errors. In some 
cases, it was difficult to determine whether strange data 
in the catalog cards generated were due to a bug in a program 
or due to an error in the data. This pointed out the desira- 
bility of an easy and inexpensive way to look at the data in 
an individual MARC record. Sequentially searching for a 
particular record in a file as large as the MARC file is an 
expensive operation. Pulling off the record in question in 
the next run by submitting a request for it was the best 
solution that could be thought of during this project. Reports 
of all potential MARC data errors were sent to the Library of 
Congress . 



Some of the card sets considered unacceptable by 
Inforonics wero used by tho libraries. When alternate class 




128 



■.i 

V. 

l 



100 . 



numbers were present in the call number field, for example, 
incorrect data was output in some cases because of a bug 
in one of the programs. V/hen the University of Vermont re- 
quested one copy of the main entry for cataloging purposes 
and incorrect data appeared in the Library of Congress call 
number, it did not •affiec.t their use of the card but it was 
still counted as a bug. Slight errors in format which the 
libraries might nonetheless consider acceptable were also 
considered bugs. 

A frequent comment made about computer produced 
catalog cards is that they take up too much space in the 
catalog because line printers print 10 characters to an 
inch horizontally and S lines to the inch (usually) vertically. 
Large libraries are especially concerned with the bulk factor. 
During the demonstration runs, the number of records that 
were contained on one card, two cards, etc. were counted 
for over 1,300 titles. Comparison figures were obtained 
from the Processing Department of the Library of Congress on 
their printed carus and are shown below: 
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NELINET MARC II 
CARDS 


LIBRARY OF CONGRESS 
PRINTED CARDS 


One card 


79 » 9% 


87 . 8% 


Two cards 


16.7% 


10.0% 


Throe cards 


2.5% 


1.6% 


Four cards 


. 6 % 


.3% 


Five cards 


.1% 


.2% 


Six cards 


.2% 


.1% 



Inforonics had been expex‘1 meriting with various 
continuous form curd stocks, lino printers, ribbons, and 
print chains for another customer, the Air Force Cambridge 
zn-r»o-avoh Laboratory library , to achieve higher quality line 
printed catalog cards . During the demonstration runs , 
different combinations of card stock, ribbon, and print 
chains wore used and tho librarians were asked to evaluate 
the quality of the products. Their preferences were as 
follows: 



Connecticut 



Massachusetts 



New Hampshire 



Rhode Island 



University Products cream stock, 
Courier Train, Letter quality ribbon. 
Rand white stock, Courier Train, 

Mylar ribbon. 

University Products cream stock, 
Courier Train, Mylar ribbon. 

Rand white stock, Courier Train, 

Mylar ribbon. 
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Vermont - Rand white stock, Courier Train, 

Mylar ribbon. 



4.2.4 Turn Around Times 

Of the five official demonstration runs, catalog 
cards v/ere mailed three (working) days after the libraries 
transmitted the requests for one run and two days after the 
libraries transmitted requests for three runs. All output 
from the last run (November 5th) was held until the replace- 
ment tapes were received and the statistics were manually 
derived. The last shipment, therefore, was mailed two and 
one half weeks after the requests were transmitted. 

The usual procedure was to run at the PDP-10 
service bureau the same day as the requests were received or 
the next morning. The output magnetic tape was then taken 
to the line printer and usually run the day after the requests 
were received. The cards v/ere then picked up, proofread, etc. 
and mailed first class to the libraries. 

The October 15th and 22nd runs were mailed on Friday 
and were received by the libraries on Monday; the October 8th 
run was mailed on Monday, two of tho libraries received it 
on Tuesday and two on Wednesday; the October 27th run was 
mailed on Wednesday, two of the libraries received their 
cards on Thui*sday and two received them on Friday. One 
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library did not receive cards on the October 8th run because 
the "/" was input instead of the " in all requests and one 
library did not receive any cards in the October 27th run 
because none of their new requests submitted in that run were 
found on the MARC tapes when initially run. It would appear 
that libraries could expect to receive cards one to two 
working days after they were mailed from Inforonics. 



4.2.5 Other Problems 

Some of the problems encountered have been described; 
a few others deserve mention. An incorrect Library of Congress 
card number was reported by one library. They received cards 
for the card number printed in the book, but the cards did 
not match the book. 

Another problem reported was that the branch or 
special shelf location of a book is not always known at 
request time but. only after the book has been cataloged. 

The card sets receivod in such case*? will, of course, not 
boar* the correct location symbols. 

4.2.6 Machine Running Costs 

The computer running costs for each of the machine 
operations are summarized in Table 4-8. These costs are 
the program running costs and do not include set up costs 
such as tape mounting and dismounting in the LC MARC II TO 
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OPERATION 


COST/ 

INPUT RECORD 
PROCESSED 


INPUT 


LC MARC II TO NELINET MARC II 


.006 


MARC Records 


MARTEN 


.003 


MARC Records 


PAPER 


.011 


Request Records 


REQUEST VALIDATOR 


.003 


Request Records 


SORT KEY GEHERATOR/Requec t s 


.002 


Request Records 


SORT KEY GENERATOR /MARC 


.003 


MARC Records 


SORT (by LC Card No .) /Requests 


.019 


Request Records 


SORT (by LC Card NO.) MARC 


,003 


MARC Records 


S MERGE 


.006 


Request and 
MARC Records 


SORT (by Library) 


.013 


Title Found 


CARD AND LABEL PRODUCTION 


.065 


Title Found 


CARD FORMATTER 


.270 


Title Found 


LINE PRINTER (Cards) 


.183 


Title Found 



TABLE 4-0 

MACHINE RUNNING COSTS 
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NELINET MARC II CONVERTER. They are all based on the number 
of input records processed. Since unfulfilled requests 
remain on the file to be searched against new MRC records 
and since the coverage of MRC II data is fo.irly well de- 
fined — all current English language monographs — the 
costs, based on input requests, are very close to what the 
costs for these operations would be if figured on a titles 
found (or card sets generated) basis. 

Estimating total costs per card set generated in 
an operating system is difficult because the searching costs 
vary directly with number of records on the file and indirect 
ly with the number of records found . The total computer 
running cost, exclusive of searching, is about 60£ a card 
set generated. Searching a file of about 100,000 MARC 
records would coat about a title if 1,000 titles were 
found .in t2xe run. 
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5. ANALYSIS AND PROJECTIONS OF OPERATING COSTS 



The demonstration production runs yielded a 
considerable amount of cost data from which system operat- 
ing costs can be projected. The purpose of this section 
is to present the results of several cost analyses and 
projections useful for planners of computer based library 
technical processing systems. 

5 . 1 SYSTEM CONFIGURATIONS 

Different configurations of computer systems and 
operating procedures which make up a centralized technical 
processing service will have costs of operations peculiar 
to themselves. This section will consider only those con- 
figurations which have been studied under the NELINET 
project . 

5.1.1 Random-Access System 

One equipment configuration pertinent to the cost 
analysis Is that originally contemplated for this project. 
The important feature of this system was that all of the 
bibliographic data was to be stored in a random-access mem- 
ory. Random-access memory configuration is considerably 
rnoi'c expensive than magnetic tape configurations used in 
the initial phases of the project. However, the eventual 
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and major use of the machine form card catalog, for more 
complete technical processing services, depends on its 
availability in a random-access form. This latter consider- 
ation guided all project planning and whenever possible, 
computer programming approaches were taken in the direction 
of eventual use of a random-access system. This type of 
system is the one eventually thought to be operationally 
feasible, and a consideration of its costs, both development 
and operating, has been a topic of study during previous 
phases of the project. A specific analysis was made in the 
final report to CLR-425, namely, a projection of costs re- 
quired to produce cards, Selin labels, and pocket labels 
via a random-access system. This projection will be examined 
in the light of the present project experience, and where 
necessary, will be updated. 

5.1.2 MARC I Tape System 

The second configuration pertinent to project 
activities was the MARC I tape system, which was developed 
and demonstrated under CLR grants 374, 385, and 425. This 
system searched a magnetic tape data base of MARC I biblio- 
graphic records to produce cards, Selin labels and pocket 
labels for the participating libraries. Computer cost data 
were collected for this system and will be compared with 
the computer costs measured in the MARC II tape system. 



o 

ERJC 



136 



108. 



5.1.3 Current MARC II Demonstration System 

A third equipment configuration to be analyzed is 
the MARC II system demonstrated under the current project 
CLR-443 . This system is functionally similar to the MARC I 
system, the main difference being that the new programs are 
improved. Also, some of the programming can be used in a 
future random-access system. Its computer costs have been 
measured and will be compared to previous demonstration 
computer costs . 

5.1.4 Proposed Magnetic Tape Operating System 

Until resources can be found to cover the capital- 
ization needed to procure a random-access system, it appears 
that the present demonstration system, with some modifica- 
tions, can be run in production. An estimate of the cost 
of this production operation will be made. The cost estimates 
of each computer processing function were derived by using the 
measm*e<i costs obtained from the MARC II demonstration in- 
creased by approximately 15-20% for fee and overhead due to 
reruns. Labor, material, and communications costs were 
derived by estimating time and amounts of material required 
and then calculating costs. 
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5.2 FACTORS FOR CONSIDERATION IN COST ANALYSIS 

There are several factors which should be considered 
in the cost analysis procedure. 

5.2.1 Experimental Costs vs. Production Costs 

Much of the work done for the NELINET project has been 
experimental, and as such, has incurred costs not applicable to 
a production environment. There have been labor costs required 
to monitor the operation, to solve problems, to collect data, 
etc. These costs include production labor as well as develop- 
ment labor, but it was impossible to distinguish between them 
in the course of the demonstration. Therefore, no labor costs 
were measured. 

A second cost category is telecommunications cost. 
This, like labor cost, was difficult to separate into produc- 
tion cost and experimental cost during the demonstration and 
therefore was not measured. 

A third major category of cost is computer cost and in 
the experiment, there were costs associated with bad runs and 
re-runs which were not applicable to production costs . These 
are easier to distinguish because equipment usage occurs in 
discrete units and these units are logged by the computer . 

The project personnel, in running the test-runs, could separate 
a run that was typical of production from a run in which there 
were experimental problems. 
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Given this problem of measurable and unmeasurable costs, 
the method of cost comparison and analysis is: 1) to compare 

original computer costs measured, eliminating labor, communica- 
tions, material, and other categories not measurable; and, 

2) to estimate costs of all unmeasurable processes and present 
a comparison of projected total production system costs. 

5.2,2 Consolidation of Processing Components Into Common 
Cost Categories 

Because we are considering different systems in our 
cost comparison, all components cannot be compared on a one 
to one basis. In order to overcome differences, processing 
components must be consolidated so that similar functions are 
compared. When this does not give a true comparison, this 
will be noted. The general processing functions which make 
up the technical processing service of card, Selin label, and 
pocket label production are listed as follows: 

a. Request processing 

b. File searching 

c. Producing and delivering products 

d. File updating 

e. Fixed operating costs 

In the production comparisons, these categories will 
be broken down into labor, transmission, computer, and 
material and miscellaneous costs. 
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5.3 COST COMPARISONS 

Two cost comparisons will be made, the comparison of 
measured computer costs of the MARC 1 and MARC II demonstra- 
tions, and the comparison of the total estimated costs of 
projected operating systems. 

5.3.1 Comparison of Measured Computer Costs 

One set of costs to be compared is the machine costs 
measured during the MARC I and MARC II experiments. These 
experimental costs are also compared to the computer portion 
of random-access system costs presented in the final report 
to CLR-425. Theso comparisons are shown in Table 5-1. 

The significant points found in the comparison 
between MARC I and MARC II computer costs are: 

a. The request processing cost is significantly 
lower in the MARC II system, even though addi- 
tional computer checking functions are pro- 
vided . 

b. The magnetic tape search costs are not lower 
in MARC II using the time-shared system. No 
prediction was made about this, but one would 
have expected costs to be lower . As the 
present time-shared service bureau rate 
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MARC II 


MARC I 


Random 


Demonstration 


Demonstration Access 


w~ 




$ 


$ 


Request Processing Cost 








PAPER 


.011 


(x) 


(w) 


REQUEST VALIDATOR 


.003 


.027(1) 


.027(1) 


SORT KEY GEN/REQ. 


.002 


(x) 


(w) 


SORT (By LC Card No.)Req. 


.019 


.024(1) 


(w) 


Total Req. Cost $/Req. 


.035 


.051 


.027 


Search Costs 








SMERGE 


.60(2) 


.54 


.06 


Total Search Cost $/Title 


.60 


.54 


.06 


Found 








Production of Cards, Labels, 








and Pockets 








SORT (by Library) 


.013 


(z) 


.013 


CARD AND LABEL PRODUCTION 


.065 


.072 


.07 


CARD FORMATTER 


.270 


.137 


.07 


LINE PRINTER 


.183 


.617 


.10 


LABEL FORMATTER 


(v) 


.03 


.03 


POCKET FORMATTER 


(v) 


(u) 


(t) 


Total Card, Label and Pocket 








Production Costs $/Title 








Found 


.531 


.856 


.28 


NOTES: 



(1) Costs In CLR-425 report , recomputed on a per request basis. 

(2) Assumes .006/record searched x 1,000,000 records searched 
* 1,000 titles found. 

(t) Function not estimated in random access production system. 

(u) Function not part of MARC I demonstration. 

(v) No data available as program was not tested. 

(w) Function does not exist in random-access system in cate- 
gory. 

(x) Combined with another program, cost included in that 
program . 

(y) Function included in communication cost. 

(z) Done manually, cost not available. 

TABLE 5-1 

COMPARISON OF MEASURED COMPUTER COSTS, MARC I, MARC II, AND 
COMPUTER COSTS OF FUTURE RANDOM ACCESS SYSTEM 
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schedule stands, the input-output cost of the 
magnetic tape process is as high as an equiva- 
lent stand-alone machine. This is an area 
which warrants further investigation in 
future work. 

c. Card production costs are lower in MARC II 
than in the MARC I system, even though the 
records are machine sorted back into library 
input order before card sets are printed, a 
feature not performed in the MARC I system. 

d. The card formatter costs are higher in the 
MARC II system. Tim© and availability of funds 
did not permit an analysis of the program oper - 
ation which would show why this occurred. 

e. The line printer cost is lower in MARC II than 
in MARC I because a faster computer line printer 
was used. Two-up printing was not used as 
proposed, because w© anticipated * high computer 
cost of outputting records for two different 
libi'aries - side by side - and because no 
methods for cutting the cards printed two- 

up were available at the time of program 
design. 
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When comparing the MARC II computer coots against 
the computer costs of the Random-Access System projected in 
the Final Report on CLR-425, the important points uncovered 
were : 



a. The magnetic tape searching cost was high by 
a factor of ten over the random-access cost . 

This was expected. 

b. The cost of sorting card sets by library ap- 
peared minimal in the demonstration. This 
suggests that further sorting by subject, 
title, and author may save manual processing 
costs at the libraries, 

5.3.2 Comparison of Production System Operating Costs 

A proposed magnetic tape service will be compared 
with the previous random-access projection and, where the 
random-access cost is unrealistic, it will be revised. 

This comparison adds costs of labor, material and transmission 
to the equipment costs to arrive at a final estimate of oper- 
ating cost. In order to compare a magnetic tape systom with 
a random- access system, a typical run of a batch of requests 
must be used. A batch of 2,000 requests searched against 
a file of 100,000 records, with an 35% match rate was 
assumed, the same rate as that used in the previous estimate 
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made under CLR-425. These comparisons are shown in Table 5-2. 
The computer charges have been increased by from 15% to 20% to 
cover a computer overhead and fee cost which was not included 
in measured costs based on service bureau billings. Points of 
comparison are: 

a. The labor cost for the magnetic tape system is 
higher than for the random-access system because 
of the Teletype monitoring and messenger service 
required to achieve a rapid response to requests . 
In the random-access system, the Teletypes are 
connected directly and a line printer would be 
located at the computer so that the only labor 
required would be the computer operation and 
the cutting, packaging and mailing of cards 

and labels. 

b. The communication costs for requests are as 
projected in CLR-425. It should be noted that, 
as the Teletype load increases for a library, 
through other library or University facilities 
bearing a portion of the fixed communication 
costs, it will be advantageous to connect dir- 
ectly to the computer as the labor cost to tend 
a Teletype is nearly equal to the message cost. 
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MARC II MAGNETIC TAPE SYSTEM 





Material 


Labor 

i 


t 

Tr ansmiss ion 

l 


J 

i 

i 

I Computer 

i 

i 

i 

l 


! 

. Total 

i 

1 


I Request Processing $/Request 

Monitor Teletype Reception 
'Monitor Running Paper 
Dataphone Cost 
Run PAPER 

Run REQUEST VALIDATOR 

Run SORT KEY GENERATOR (reqs . ) 

Run SORT (reqs.) 




.03 

.03 


.014 


.013 
.005 
.004 
. 014£> 


60.00 

60.00 

28.00 

26.00 

10.00 

8.00 

28.00 


Total Request Cost by Category 




.06 


.014 


.036 




Total Request Cost/Request 








.11 




Total Cost 2,000 Requests 




120.00 


28,00 


72.00 


220.00 


II File Search 












Run SMERGE 








7.00/ 


700.00 










1000 recs . 




Total Cost/1,000 Records 












Searched 








7.00 




Total Coat/100 ,000 Records 












Searched 


i > i Mia - - 






700.00 


700.00 



(a) Random-access cost is per request. 

(b) Cost is higher because transmission was from Burlington Vermont 
to computer, not from Maynard t* computer. 

(c) Best experimental sort run cost was taken as a base rather 
than average 



' TABLE 5-2 

COMPARISON OF OPERATING COSTS OF MAGNETIC TAPE PRODUCTION SYSTEM 
WITH THOSE OF A RANDOM-ACCESS SYSTEM (ASSUME 100,000 RECORD FILE, 
2,000 REQUESTS ONCE A WEEK, 85% MATCH RATE, 1,700 TITLES PRESSED.) 
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RANDOM ACCESS SYSTEM CLR 425 REVISED RANDOM ACCESS SYSTEM 




TABLE 5-2 

COMPARISON OF OPERATING COSTS OF MAGNETIC TAPE PRODUCTION SYSTEM 
WITH THOSE OF A RANDOM-ACCESS SYSTEM (ASSUME 100,000 RECORD FILE, 
2,000 REQUESTS ONCE A WEEK, 85% MATCH RATE, 1,700 TITLES PROCESSED.) 

v-C- 

V 

> ■ 
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MARC II MAGNETIC TAPE SYSTEM (Cont'd.) 



pH 




a 

o 

*H 

CO 

CO 


u 


d 




•H 


<D 


•H 




s 


+» 


u 


u 


CO 


g 


o 


0 


a 


A 


+3 


ja 


d 


e 


d 

S 


a 


m 


o 

o 



Ill Production & Delivery - 
Pockets , Labels , Cards - 
Cost/Title Matched 

Run SORT (Matched requests 
per Library) 

Run CLPP 

Run PUFF 

Run Pockets 

Run Label 

Run Card Printer 

Run Pocket Printer 

Cut cards 

Print labels 

Postage 

Material & Misc. Equipment 



03 

,006 



,04 

,14 



rH 

CJ 

O 



.018 


30.60 


.069 


117.30 


.294 


499 . 80 


.070 


119.00 


.030 


51.00 


.174 


295 . 80 


.017 


28.90 

51.00 
10.20 

68.00 
238.00 



Total Production & Delivery 






Cost by Category 


.18 .036 


.672 


Total Production & Delivery 






Cost 




.888 


Total Production & Delivery 
Cost/1,700 Titles Matched 


306.00 61.20 


1142.40 1509.60 



TABLE 5-2 (Cont f d*) 

COMPARISON OF OPERATING COSTS OF MAGNETIC TAPE PRODUCTION SYSTEM 
WITH THOSE OF A RANDOM-ACCESS SYSTEM (ASSUME 100,000 RECORD FILE, 
2,000 REQUESTS ONCE A WEEK, 85% MATCH RATE, 1,700 TITLES PROCESSED.) 
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RANDC M-ACCESS SYSTEM CLR 425 (Cont'd.) REVISED R ANDOM-ACCESS SYSTEM (Con 



a 

•H 

U 

O 

+> 

a 

as 



o 

43 

a 



C3 

o 

•H 

(0 

(0 

•H 

s 

02 

a 

cJ 



.03 

.13 



.16 



,03 

,01 



,04 



272.00 68.00 



! 

j 

Computer J 

1 


H 

d 

0 

Eh 


Material 

j 

i 


Labor 


Transmission 


1 

i 

j 

♦ 

t 

Computer J 

! i 


i 

Total 












.018 


30.60 


.07 


119.00 








.07 


119.00 


.07 


119.00 








.14 


238.00 












.07 


119.00 


.03 


51.00 








.03 


51.00 


.10 


170.00 








.10 


170.00 












.017 


28.90 




51.00 




.01 






17.00 




17.00 




.006 




10.70 




51.00 


.04 








68.00 




221.00 


.14 








238.00 


.27 




.18 


.016 


44.5 




.47 










64.1 




459.00 


799.00 


306.00 


27.20 


756 . 50 


1089.70 










— 


— 





TABLE 5-2 (Cont*d.) 

COMPARISON OF OPERATING COSTS OF MAGNETIC TAPE J^DUCTION SYSTEM 
WITH THOSE OF A RANDOM-ACCESS SYSTEM (ASSUME 100,000 RECORD FILE 
2,000 REQUESTS ONCE A WEEK, 85% MATCH RATE, 1,700 TITLES PROCESSED.) 
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MARC II MAGNETIC TAPE SYS TEM (Cont'd.) 



e 

0 

















to 






rH 




CO 


u 




Ctf 






© 




•H 




6 


+> 




u 


u 


CO 


3 


rH 


© 




c 

a 


e 


d 

4-> 


ci 


eS 


u 


0 


0 


*rrS 






o 


Eh 



IV Fixed Operating Costs/Run 
(week) 

Monitor REQUEST VALIDATOR 



Through PUFF 

Dataphone Cost From REQUEST 


27.00 






27.00 


VALIDATOR Through PUFF 




10.80 




10.80 


Dataphone Cost Fixed Monthly 
Computer Logging Error 




48.00 




48.00 


Control 






4.50 


4.50 


Messenger Service To Printer 


23.30 






23.30 


Package For Mailing 


9.00 






9.00 


Total Fixed Operating Costs 










by Category 




58.80 


4.50 


122.60 


V File Updating Cost/Run (week) 










LC MARC II TO NELINET MARC II 


• 




15.00 


15.00 


Messenger Service 


52.20 






52.20 


Run MARTEN (LC MARC II) 
Run SORT KEY GENERATOR 






5.20 


5.20 


(LC MARC II) 






6.60 


6.60 


Run SORT (LC MARC II) 






14.40 


14.40 


Total File Update Cost by 








93.40 


Category 


52.20 




41.20 


Total Production Cost per 










Weekly Run 306^00 


292.70 


86.80 


1960 . 10 


2645.60 


Total Cost per Title 










..... .M&tfibed . 


^ 


— 


— — ... 


1. 56.. 



TABLE 5-2 (Cont’d.) 

COMPARISON OF OPERATING COSTS OF MAGNETIC TAPE PRODUCTION SYSTEM 
WITH THOSE OF A RANDOM-ACCESS SYSTEM (ASSUME 100,000 RECORD FILE, 
2,000 REQUEST'S ONCE A WEEK, 85% MATCH RATE, 1,700 TITLES PROCESSED.) 
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RANDOM-ACCESS SYSTEM CLR 425 (Cont.d) REVISED RANDOM ACCESS SYSTEM (Coni' c 



! ! 

! j 

Material ! 

s 

i 

i 

t 

Labor ! 

1 

i 

i 

t 

I 

Transmission ! 
__ 

i 

i 

total 

1 

J 


Material 

Labor 

Transmission 

j 

Computer 

Total 


.05^) 85.00 

27.00 27.00 

.010) 17.00 


27.00 27.00 

34.00 34.00 

4.50 4.50 

Q no 9..Q0. 


102.00 27.00 129.00 


36.00 34.00 4.50 74.50 




15.00 15.00 

5.20 5.20 

6.60 6.6C 

14.40 14.40 


Not Estimated 


41.20 41.20 


272 .00 170.00 107.00 639.00 1188.00 


306.00 63.20 114.00 1122.20 1605.40 


.70 


.95 

rs — riTP — 



\U/ UttUUA VWD V wiuyu wvv» ~ 

TABLE 5-2 (Cont'd.) 

COMPARISON OF OPERATING COSTS OF MAGNETIC TAPE PRODUCTION SYSTEM 
WITH THOSE OF A RANDOM-ACCESS SYSTEM (ASSUME 100,000 RECORD FILE, 
2,000 REQUESTS ONCE A WEEK, 85% MATCH RATE, 1,700 TITLES PROCESSED.) 



d 

ERIC 



150 



122 . 



c. The cost of acceptance of a request, validating 
and temporarily storing it, is as projected in 
CLR-425. In a future plan, the estimate is 
raised to allow for additional checking and 
message printout . 

d. The search cost is a large share of the computer 
expense and is six times that of a random-access 
memory projected in CLR-425. Because of the 
poor reliability achieved on large random-access 
memories during our time-shared computer experi- 
ence, we estimate random-access cost to be 
double the previous estimate of $.06 and the 

new projection is revised accordingly . The cost 
estimate was doubled because the simplest and 
quickest way to achieve reliability would be to 
double the memory size and thus the cost, using 
one half for backup. 

The search cost for a magnetic tape system is 
more or less favorable, depending on the ratio 
of requests to total file size. If a large 
number of requests can be searched, compared 
to the file size, then the search cost will 
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be low. 
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e. Because the demonstration, as mentioned before, 
showed the card formatting costs to be higher 
than projected, we estimate that these costs 

in a magnetic tape production system will be 
higher. 

f. Material and postage costs in the MARC II mag- 
netic tape production system were slightly 
higher than the random-access projection made 
in CLR-425 so the revised projection shows this 
increase. 

g. It is still expected that a two-up printing sys- 
tem can be developed in the future so that print- 
ing costs will be as previously estimated. 

5.4 FUTURE COSTS OF THE PROPOSED MAGNETIC TAPE OPERATION 

Four XttCtUlo Virhioh will influcUCC the 

iiio.fciion.o opex*ating cost in the future are described 

below. 

5.4.1 Time-Shared Computing Costs 

The present situation with time-shared computing 
costs is changing with respect to the NELINET type of pro- 
duction. The rates quoted are those for numerical calcula- 
tion type of work. The net effect of these factors is that 
the computing costs should decrease slightly. 
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5.4.2 System Overhead Costs 

An experiment or demonstration does not yield 
definite data about operational system overhead costs. 

These include such things as the costs of : adding new custo- 

mers, responding to errors and complaints, improvements in 
the system, training of system personnel, planning of major 
improvements or new services, and accounting and administra- 
tion. 

Computer overhead and systems maintenance costs 
have not been estimated for the MARC II magnetic tape system 
or the revised random-access system. These costs vary and 
depend on the desired rate of system improvement. 

The original estimates of system improvement com- 
puter overhead rates are still reasonable for any revised 
projection. Definite technical development plans are needed 
before they warrant changing. 

The accounting overhead costs can be lowered some- 
what because most accounting functions required are avail- 
able on a time-sharing system. 

5.4.3 Initial Production Costs vs. Future Production Costs 

Another problem which arises in analyzing costs 
is distinguishing initial production cost from on-going 
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production costs. An initial system is the result of an 
analytical design and such a design never can consider all 
of the small operations which make up the major components. 
These are brought to light by operating the system. The 
present state of the demonstration has not seen the system 
operational long enough to identify all of the areas for 
improvement. The net effect, presumably, is that the future 
costs will be lower as the improvements are made. 

5.4.4 Significant Technical Innovation 

If financing prohibits one from following the 
random— access approach, then there are techniques of mag- 
netic tape file organization and searching which can be used 
to reduce costs. Up until now, techniques have not been 
pursued and are not discussed because it was expected that 
a random— access memory approach was eventually going to be 

used. 




154 



APPENDIX A 
Request Worksheets 
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A - 1 



ERIC 



NELINET MARC II REQUEST WORKSHEET — UNIVERSITY OF CONNECTICUT 
Filled in by Teletype Operator: 



req^ 





Day 


No. 


no raf 


co69- 


1- 1- 


_J u 





Filled in by Cataloger: 



crd <_ 



loc^_ 
loc<_ 
loc 
loc 
loc^- 
loc 4 - 
loc 
loc 4 - 



Location Symbol (s) 


Copy No(s) 


Vol. No(s) 


No Cd 


No S 


NoBk 


xMt 


1. 


2 . 


3. 


4. 


5. 


6 . 


7. 


1. 


2 . 


3. 


4. 


5. 


6 . 


7 1 


1. 


2 . 


3. 


4. 


5. 


6 . 


7. 


1. 


2 . 


3. 


4. 


5. 


6 . 


L- 


1. 


2. 


3. 


4. 


5. 


6 . 


7. 


1. 


2 . 


3. 


4. 


5. 


6 . 


7. 


1. 


2 . 


3. 


4. 


5. 


6 . 


7. 


1. 


2 . 


3. 


4. 


5. 


6 . 


7. 



cbTU. 



Valid Location Symbols 



Acq. 

Bibl. 

Catl. 

G.P.D. 



Music 

Pharm. 

Ref. 

Spec. 
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NELINET MARC II REQUEST WORKSHEET— UNIVERS ITY OF MASSACHUSETTS 
Filled in by Teletype Operator: 







Day 


No. 


no raf 


req^- 


ma69- 


i i 


. 1-1 - 





Filled in by Cataloger: 



crd <- 



loc {- 
loc 4- 
loc 4 r 
loc 
loc 
loc (- 
loc 4r 

loc (. 



Location Symbol(s) 


Copy No(s) 


Vol . No(sT 


No Cd 


No S - ' 


No Bk 


xME 


1. 


2. 


3. 


4. 


5. 


6. 


7. 


1. 


2. 


3. 


4. 


5. 


6. 


7. 


1. 


2. 


3. 


4. 


5. 


6. 


Zj_ 


1. 


2. 


3. 


4. 


5. 





7 


1. 


2. 


3. 


4. 


5. 


6 . 


7. 


1. 


2. 


3. 


4. 


5. 


6 . 




1. 


2. 


3. 


4. 


5. 


6_* 


7. 


1. 


2. 


3. 


4. 


5. 


6 . 


7. 



call^- 



Valid 


Location Symbols 


AG EN 


HOME 


PLANT 


BURGO 


LABOR 


PSYCH 


BUS 


LAND 


REF 


CHEM 


MATH 


RES C 


CRAN 


MORR 


SHADE 


EDUC 


MUSIC 


SPEC 


ENGIN 


NUR 


TECH P 


ENT 


PER 


VET 


FOOD 

FOR 


PHYS 


WALT 
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NELINET MARC II REQUEST WORKSHEET — UNIVERSITY OF NEW HAMPSHIRE 
Filled in by Teletype Operator: 



req 



nh69- 




no raf 





Filled in by Cataloger: 



ci*d^ 





Location Symbol (s) 


Copy No^s) 


iVol . No(s) 


No Cd 


o 

CO 

i 


No Bk 


xME, 


lOC^s- 


1. 


2. 


1 3 . ' 


4. 


5. 


6. 


7. 


loc <T 


1. 


2. 


1 

t 

3. 


4. 


5. 


6. 


7. 


loc<- 


1. 


2. 


3. 


4. 


5. 


6. 


7. 


loc<- 


1. 


2. 


3. 


4. 


5. 


6. 


7. 


lo<?.<- 


1. 


2. 


ia. 


4. 


5. 


6. 


7. 


loo < 


1. 


2. 


3. 


4. 


5. 


6. 


7. 


loc<- 


1. 


2. 


3. 


4. 


5. 


6. 


7. 


loc 4 


1. 


2. 


3, i 


4. 


5. 


6. 


7. 






Valid Location Symbols 



Archiv 


LS 


Nt 


Biochm 


LSj 


Pam 


BioScl 


LSRef 


Per 


Browse 


Math 


Phys 


Call 


Mcard 


Ref 


Chem 


Mfiche 


RefBib 


Eng 


Mfllm 


Spec 


German 


Mprint 


Vault 


Hj 


MS 


y 


j 


NH 





158 
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NELINET MARC II REQUEST WORKSHEET— UNIVERSITY OF RHODE ISLAND 
Filled in by Teletype Operator: 



req^_ |ru69- 



no mf 



Filled in by Cataloger: 



crd <- 



loc-*- 
loc 4 - 
loc 4 - 
loc 4 
loc 4 . 

loo 4. 

loc 4 - 
loc f 



Location Symbol (s) 


Copy No(s) 


Vol NoCs) 


No Cd 


tfo S 


No Bk 


xME 


1 . 


2 . 


3. 


4. 


5. 


6 . 


7. 


1 . 


2 . 


3, 


4. 


5 r 


6. 


7. 


1 . 


2 , 


3^ . 


4, 


5» 


6 , 


7. 


1 . 


2 . 


3, 


4. 


5 f 


6 . 


7. 


1 . 


2 . 


3. 


4. 


5. 


6 . 


7. 


Ll 


2 . 


3. 


4. 


5. 


6 . 


7. 


1 . 


2 . 


3. 


4. 


5. 


6 • 


7. 


1 . 


2 . 


3. 


4. 


5. 


6 . 


7. 



cal 1 4. 



Valid Location Symbols 



Archiv 

Blatz 

EXT 

J.F.K. 

mcard 

mfiche 



mfilm 

NML 

R.I.C1 

Rare 

Ref 
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NELINET MARC II REQUEST WORKSHEET— UNIVERSITY OF VERMONT 
Filled in by Teletype Operator: 







Day 


No. 


no raf 


req<- 


vt69- 


. I 1, 


1 1 





Filled in by Cataloger: 



crd 





Location Symbol (s) 


[Copy No(s) 


Vol. No(s) 


No Cd 


No S 


No Bk 


xME 


loc X- 


1. 


2. 


3. 


4. 


5. 


6. 


7, 


\ 

loc 


1. 


2. 


3. 


4. 


5 f 


6. 


7 , 


A 

loc {- 


1. 


2. 


3. 


4. 


5. 


6. 


7 f 


loc 


1. 


2. 


3. 


4. 


5. 


6. 


7 f 


loc. 


1. 


2. 


3. 


4. 


5. 


6. 


7 f 


loc 


1. 


2. 


3. 


4. 


5. 


6. 


7. 


loc f- 


1. 


2. 


3. 


4. 


5. 


6. 


7 f 


loc f. 


1. 


2. 


3. 


4. 


5. 


6. 


7. 



calif- 



Valid Location Symbols 



J 

Mfilm 

MP 

Per 

R 



RIndex 

S 

TR 

W 
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APPENDIX B 



Catalogers * Instructions for 
Filling Out Request Worksheets 
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NELINET MARC II 



Catalogers f Instructions for Filling Out Request Worksheets 

(Use Red Pencil) 



req - Request Number 

The Request Number is an identification number given to 
each request. It must be present in each request and it must be 
the first piece of data transmitted. It contains the library input 
code, the last two digits of the year, and a 1-6 digit sequence 
number . 



The library's input code and the year have been pre- 
printed on the forms. The sequence number is assigned by the 
requesting library. Either one of the two following schemes may 
be used to assign the sequence number: 

(1) One sequence of numbers may be used for the 
entire year, if such a scheme is used, the 
first and last requests might appear as fol- 
lows : 




(2) A new sequence of numbers may be used for each day's 
transmission. In this scheme, the first three digits 
represent the day of the year (the days being number- 
ed from 1 to 365 or 366) and the last three digits 
represent the number of the request in the day's 
batch of requests. In this scheme high order zeros 
should fill out each of these numbers to three digits. 



req f 





Day 


~so: 


no mf 


vt69- 


OJOLL 


^>i / 1 1 





1/2/69 
12 th 
request 
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Day 


No. 


no mf 


req«- 


vt69- 


LLHI 


ai q i/ 





6/30/69 

1st 

request 



If the record is not to go on the library’s 
master (holdings) file, record an "m" in 
"no mf". (An example of the use of this 
feature is shown In the call number section 
of these instructions.) 




The matched requests will be sorted back by the 
library’s request number. If a library desires 
an internal arrangement within a day’s batch of 
requests, e.g. by main entry, they should arrange 
the requests (or the books) in that order and 
then number the requests . 

crd - LC Card No . 

Record the Library of Congress card number here. Include 
prefixes if present. Suffixes can be ignored. 



crd 



~~ cLLa. T. <2± 




crd <- 

loc - Lo cati on— -Copy— -V olume Data 



Each "loc” data field (line) contains the information for 
the copies (or volumes) in a particular location. The NELINET work 
sheet presently provides for recording data for eight locations. 
This may be expanded if it is found to be insufficient. Whenever 
more than eight locations are to be recorded for one title, the 
additional ones may be recorded on another worksheet noting the 
first worksheet accordingly. If no "loc" data is recorded on a 
worksheet, main library-main stacks — copy one will be assumed. 
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1. Location Symbols 



Record location symbols as they are to be printed. A 
location symbol should not contain more than six characters, 
including periods. If more than one symbol is required for a 
particular location (e.g., a special shelf location within a 
branch library), separate symbols with slashes. Up to three 
location symbols, including oversize, may appear on catalog cards. 
Each location symbol will be validated against the location symbol 
table in requesting library's profile. 

Examples : 



loc«- 



Location Symbol (s) 

i- Rtf- 



loc 



Location Symbol(s) 



NOTE: The last line segment does not require 

a slash. 



If nothing is recorded in the location symbol block, 
main library, main stacks will be assumed. The oversize symbol 
should not be recorded. It will be generated by the program. 

2 . Copy .Numbers 

i 

’’Copy" is abbreviated as small letter "c" followed by 
a period, ”c.". Single copies may be recorded as "c.l”. If 
nothing is recorded in the copy number block, "c.l" will be 
assumed . 



Multiple copies consecutively numbered are recorded by 
preceding the range of copy numbers with a dollar sign e.g. 
$c . 1-10 . 



Multiple copies (in a particular location) not consec- 
utively numbered, must be recorded individually. Each copy 
number (or range of consecutively numbered copies) is recorded, 
separated by commas, e.g., c.l, c.4; $c.l-3, c.5; or 
$c . 1-3, $c . 6—9 . 



NOTE: The ’’c.’’ must appear before each individual 

copy number or each range of copies. 




Examples : 



B - 4 



Copy No. (s) 



2 . 



copy one assumed 



Copy flo. (s) 



?• CLS 



Copy Wo. is) 



2 . $ Q ./-/6 



Copy No.(s) 



2. 



Copy No. (s) 



2. q,yg, G.6 



Copy No. (s) 



3Jc . 



NOTE: As stated previously, main library — main stacks- 

copy one is assumed if the worksheet does not 
contain any "loc" data. If, however, the work- 
sheet does contain some "loc 7 ' data and copy one 
is located in the main stacks of the main li- 
brary, this must be stated: 



loc <- 
loc 



Location Symbol (s) 


Copy No. (s) 


1. 


a. e. l 


l. 


2 



|ERJC 
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3 . Volume Numbers 



Volume numbers are recorded in the same fashion as copy 
numbers — a dollar sign precedes consecutively numbered volumes, 
and commas separate nonconsecutive volume numbers (individual 
volume numbers or ranges) . 



/ 



lOC <r 



Location Symbol (s) 


Copy No(s) 


voi. Nocsr 


h 


2 . at 


3Jv.l-5 



/ 



/ 



/ 



loc 



Location Symbol (s) 


Copy No(s) 


Vol. No(s) 


1 . 


2.sfc i -JL 


3.$ V. / 



loc 4- 



Location Symbol (s) 


Copy No(s7 


Vol. Ho(sT 


1 • C.h 


2.0-3 


3.V .'/ ' V/.Y 



loc/~ 



Location Symbol (sF 


Copy No(s) 


Vol. No(s) ' 


1. 


2 .QJ, H-4/ 


/ 

h3j )/• h 



As indicated above in the second example, multiple 
copies of the same range of volume numbers' ($v,l-5) can be 
recorded in one "loc" statement. If, however, at one loca- 
tion the same volume numbers are not contained. in each set, 
a different procedure should be followed. If, for example 
the Chem. branch (or any other location) owned three copies 
of volumes 1 and 2 but only one copy .of volumes 3, 4, and 5, 
two "loc" statements would be required. As shown below, 
catalog cards should be suppressed Jin one of the "loc" state- 
ments . / 



/ 
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Location Symbol is) 


Copy No(s) 


VoIT.~N6CsT 


Wo CdT 


1. CjzLti x 




3 dfv. ! -& 


4. 



Location Symbol (s) 


Copy No(s) 


VSTTMtsT 


No Cd. 


1. Q-h . 


2 . a . / 


3 & \L s3 -vr 


iaJC 



The example cited above could also be recorded as : 



loc 



loc {. 



Location Symbol (s) 


Copy No(s) 


Vol. ffSTs) 


No CuTl 


1. Oh £ho , 


2. a,/ 


3 *3$. lA 


4. 



Location Symboils) 


Copy Nois) 


VoITUoTsJ" 


No Cd. 


1. 


2 .J Q-A-Z. 


3sd V. 


o<L 





When a physical volume contains more than one biblio- 
graphic volume, the range of volume numbers is recorded without 
anv dollar sign e.g., two physical volumes, one containing bib- 
SX.SSio volumes 8 ! and 2 and the other containing bibliograph- 
ic volumes 3, 4, and 5, would be recorded as: 



Location Symbol (s) 


Copy Wo(s) 


Vol. Wo(s) 


1. 


2.0./ 


3.V/-Z.V.3S 



Volume designations other than volume (v.) can be 
enumerated if the volume designation (or its abbreviation) , and 
the number of the volume do not exceed six characters. 



e.g. , Pt .1-3 or N.l-2 

A period should always follow the abbreviation when 
volume numbers are enumerated . 

Volume designations other than the simple type noted in 
the p ar a g raph above cannot be enumerated and each physical volume 
should be recorded individually. 

e.g., 1949 or ser. 349 
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When a volume designation exceeds six characters, the 
program will look for a space, hyphen, slash, or period and break 
at this point. The hyphen, slash, or period will be retained. 

4. No Cd. - Suppress Catalog Cards 

If catalog cards are to be suppressed for this request, 
record an M x" in this block. 

5. No S - Suppress Selin Labels 

If Selin Labels are to be suppressed for this request, 
record an "x M in this block. 

6. No Bk - Suppress Selin Labels 

If book pocket labels are to be suppressed for this 
request, record an ”x” in this block. 

7. x ME - Extra Main Entries 

If extra main entries are desired, record the number 
wanted in this block. Up to seven may be requested. 

call - Local Call Numbers 



Whenever a call number other than the one established at 
the Library of Congress is to be used, record it here, separating 
the segments that are to appear on each line with slashes. No 
more than six characters may be included in one line segment. 
Location Symbols are not recorded as part of the call number - 
they are recorded in the "loc" statement. 

calif- 6^ C) . ! (du. - ■ — 

calif f±g/A2A/L n VLSI 

NOTE: (1) The last line segment does 

not require a slash. 

(2) A period does not precede the 
Cutter Number . 

If nothing is recorded here, the call number established 
at the Library of Congress will automatically be placed in the 
10 ft margin of tho catalog cards and on the labels. It will be 
broken as follows: 
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DS 

2416 

R8 

H764 

1966 

Vol. 

2467 

Libraries nay use the system to obtain LC cataloging 
copy. To do so, record an "m" in the "no mf" block of the 
request number, suppress catalog cards, Se&jb£ labels and book 
labels, request one extra main entry, and leave the "call" 
line blank as in the following example: 
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NELINET MARC II REQUEST WORKSHEET-UNIVERSITY OF RHODE ISLAND 
Filled in by Teletype Operator: 



reqe- 



ru69- 


oL (a v5 


no mf 

/XU 


l in by Cataloger: 


i 




12AR 


i 

t 



crd<- 



lOCf- 

loc<- 

lOCf 

loc<~ 
loc (- 
lOCf- 
locf- 
loc f 

call f- 



Location Symbol (s) 


Copy tfo(s) 


Vol. No(s) 


No Cd 


F<rir 


r floW 


E3ga 


1 . 


2. 


3. 


4. y 


5./ 


«-X 




1 . 


2. 


3. 


4. 


5. 


6. 




1 . 


2. 


3. 


4. 


5. 


6. 


7. 


1 . 


2. 


3. 


4. 


5. 


6. 


7. 


1 . 


2. 


3. 


4 a 


5. 


6. 


7 . 


t 

1 . 


2. 


3. 


4. 


5. 


6. 


7 1 


1 . 


2. 


3. 


4. 


5. 


6. 


7. 


1 . 


2. 


3. 


4. 


5. 


6. 


7. 



Valid Location Symbols 



Archiv 

Blatz 

EXT 

J.F.K. 

incard 

mfiche 



ufilm 

NML 

R.I.C1 

Rare 

Ref 



ERJCi 



m 

V." 



170 




APPENDIX C 



Instructions For Teletypists 




C - 1 







NELINET MARC II - INSTRUCTIONS FOR TELETYPISTS 

(In the following instructions, the characters to be typed 
have been enclosed in quotation marks for clarity. 

Do not type the quotation marks.) 

A. GENERAL INFORMATION 

1. For easy reading, double space between lines. 

2. A carriage return is not complete until the line feed key is 
typed . 




t. 



r 

£ 



ip' 





3. The ASR-33 teletype does not have upper and lower case char- 
acters. To distinguish upper case characters from lower 
case characters, the up arrow "f" (shift "n") will precede 
each upper case character. 

e.g., ^‘H'tS/162 .4/TC146 

4. The tab key on the ASR-33 does not physically move the carriage. 
Tabs normally would be used to separate tags (labels) from 
data fields: 

e.g., tag data^ field 

crd 69-123 

and to separate subfields within a data field: 

Data Field 

t ^ * •> 

Subfield Subfield 

f t A % 

ioc l.Chem. 2.$c.3-4 

The character "f-" (shift "0”) will be used instead of the tab 
in these instances. A space or a number of spaces may be 
typed after this character to format the data. 

e.g., Ioc 4- l.Chem. f 2.$c.3-4 

5. Error correcting commands 

(a) To delete a single line, type "\KL" at the end of 
the line to be deleted and follow by a "carriage 
return-line feed". The correct line can now be 
typed. (The "\" is the shift "L" key.) 

(b) To delete an entire request, type "\KR carriage 
return-line feed" and begin request over again. 
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B. KEYING REQUESTS 



1. Press local ("LCL") . 

2. Press punch on. 

3. Generate a couple inches of rub outs by pressing simultaneously, 
the rub out key and the repeat key (REPT) . 

4. req ~ Request Number 

This must be present in each record and will appear on each 
worksheet as: 









no mf | 


req 4 


nh69- 


jLsLki 


i 

» 



req 


nh69- 


J2 : 


ho mf 

O/O' 












req<- 


vt69- 


)ay 

010 1/ 


Ho. 

01Z.LA 


no mf 












req <£- 


vt69- 


3ay 

)\?\a 


No. 

<31 0 1 / 


no mf 

/OtO 



and should be keyed as: 

req* NH69-126 
req* NH69-29M 
req* VT69-001012 
req*- VT69-180001M 

The operator may type as many spaces after the ”< M thinks 

will format the page nicely. 
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5. crd - LC Card Number 



This must be present in each record and will appear on each 
record as: 



crd^. 




crd*- 




and should be keyed as: 



crd* 69-123 
crd* tAGR72-61 

6. loc - Location— Copy— Volume Data 



This may or may not be present in a record. Type only the 
blocks (subfields) that have been filled in by the catalog©**. 
The "*." and one or more spaces are used to separate the sub- 
fields as well as to separate the tag (loc) from the data. 
The following location statements: 



loc 4 - 
loc f 

loc *- 

loc 4 



Location Symbols 


Copy No(s) 


Tor: woCsT 


No Cds 
4. 


ncTT 

5. 


No Bk 




1 . 


2 4c. / -JL 




6. 


7. 


1 . 


2. 


3. 


4. X 




6.>* 


7.f 


i. <; 


2. 


3. 


4. 


5. 


6 . 


7. 


1 - R 


2./ol- /-:< 


3. 


4. 


5. 


6. 


7. 



should be keyed as: 



loc<- 2.$c.l-2*. 3.$v.l-3 

loc*. 4.x* 5.x* 6.x* 7.1 

loc*. l.*S 

loc*. 1/}R(- 2.$c.l-3 
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7. 



call - Local Call Number 



This may or may not be present. It will appear on the work- 
sheet as: 

call*. £j/,/ 

and should be keyed as : 

call*- 621.1/fB62 

8. To end each request, type "\\ carriage return-line feed". The 

should appear alone on a line. 

9. The *\\ carriage return line feed" following the last record is 
sufficient to end the transmission. Follow this with a couple 
of inches of rub outs. This will separate the last request 
from any dialogue that takes place when you transmit. 

NOTE: (1) A CARRIAGE RETURN-LINE FEED MUST FOLLOW THE 

THAT ENDS THE LAST RECORD. 

(2) DO NOT TYPE ANOTHER "W". 



C. TRANSMITTING REQUESTS 

1. Set everything to the "off" condition. 

2. Make sure that the machine is on the Dataphone line, not the 
TWX line. 

3. Put the punched request tape in the paper tape reader, making 
sure it is smooth and that there are no wrinkles in it . 

4. a All libraries except the University of Con n ecticut ! 

Set the switch in the lefthand corner of the machine 
to "Automatic". Inforonics will initiate the request by 
calling the library. The transmission will then proceed 
automatically without further intervention from the library 
staff. It is desirable, however, to have someone present 
while the transmission is taking place to insure that the 
tape does not get tangled. 

4.b University of Connecticut: 

Someone must be present when Inforonics calls to push 
the switch in the lefthand corner of the machine to the 
"Start" position. The transmission will then proceed auto- 
matically. 
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